idnits 2.17.1 draft-ietf-isms-tmsm-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2312. ** 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 == Line 507 has weird spacing: '...patcher v ...' == Line 1049 has weird spacing: '...rmation sen...' == Line 1095 has weird spacing: '...rmation est...' == Line 1102 has weird spacing: '...rmation clo...' == 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 (March 4, 2006) is 6620 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) == Unused Reference: 'RFC3413' is defined on line 2065, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Downref: Normative reference to an Experimental RFC: RFC 3430 ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. 'I-D.rescorla-dtls') == Outdated reference: A later version (-06) exists of draft-ietf-netconf-ssh-05 == Outdated reference: A later version (-14) exists of draft-ietf-tls-srp-10 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft Futurewei Technologies 4 Expires: September 5, 2006 J. Schoenwaelder 5 International University Bremen 6 March 4, 2006 8 Transport Mapping Security Model (TMSM) Architectural Extension for the 9 Simple Network Management Protocol (SNMP) 10 draft-ietf-isms-tmsm-01.txt 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 5, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes a Transport Mapping Security Model (TMSM) 44 subsystem for the Simple Network Management Protocol (SNMP) 45 architecture defined in RFC 3411. This document identifies and 46 discusses some key aspects that need to be considered for any 47 transport-mapping-based security model for SNMP. 49 This memo also defines a portion of the Management Information Base 50 (MIB) for managing the Transport Mapping Security Model Subsystem. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. The Internet-Standard Management Framework . . . . . . . . 4 56 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Requirements of a Transport Mapping Security Model . . . . . . 6 59 2.1. Security Requirements . . . . . . . . . . . . . . . . . . 6 60 2.1.1. Security Protocol Requirements . . . . . . . . . . . . 6 61 2.2. Session Requirements . . . . . . . . . . . . . . . . . . . 7 62 2.2.1. Session Establishment Requirements . . . . . . . . . . 8 63 2.2.2. Session Maintenance Requirements . . . . . . . . . . . 8 64 2.2.3. Message security versus session security . . . . . . . 8 65 2.3. Architectural Modularity Requirements . . . . . . . . . . 9 66 2.3.1. USM and the RFC3411 Architecture . . . . . . . . . . . 12 67 2.3.2. TMSM and the RFC3411 Architecture . . . . . . . . . . 13 68 2.4. Passing Messages between Subsystems . . . . . . . . . . . 15 69 2.5. Security Parameter Passing Requirement . . . . . . . . . . 16 70 2.5.1. Define an Abstract Service Interface . . . . . . . . . 17 71 2.5.2. Using an Encapsulating Header . . . . . . . . . . . . 17 72 2.5.3. Modifying Existing Fields in an SNMP Message . . . . . 17 73 2.5.4. Using a Cache . . . . . . . . . . . . . . . . . . . . 18 74 2.6. Architectural Requirements for Access Control . . . . . . 18 75 2.6.1. securityName Binding . . . . . . . . . . . . . . . . . 18 76 2.6.2. Separation of Authentication and Authorization . . . . 19 77 2.7. Requirements for Notifications . . . . . . . . . . . . . . 20 78 3. Scenario Diagrams . . . . . . . . . . . . . . . . . . . . . . 21 79 3.1. Command Generator or Notification Originator . . . . . . . 21 80 3.2. Command Responder . . . . . . . . . . . . . . . . . . . . 22 81 4. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 23 82 5. TMSM Abstract Service Interfaces . . . . . . . . . . . . . . . 24 83 6. Integration with the SNMPv3 Message Format . . . . . . . . . . 26 84 6.1. msgVersion . . . . . . . . . . . . . . . . . . . . . . . . 26 85 6.2. msgGlobalData . . . . . . . . . . . . . . . . . . . . . . 27 86 6.3. securityLevel and msgFlags . . . . . . . . . . . . . . . . 27 87 7. The tmStateReference for Passing Security Parameters . . . . . 28 88 8. securityStateReference Cached Security Data . . . . . . . . . 29 89 9. Prepare an Outgoing SNMP Message . . . . . . . . . . . . . . . 29 90 10. Prepare Data Elements from an Incoming SNMP Message . . . . . 30 91 11. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 31 92 12. Transport Mapping Security Model Samples . . . . . . . . . . . 31 93 12.1. TLS/TCP Transport Mapping Security Model . . . . . . . . . 31 94 12.1.1. tmStateReference for TLS . . . . . . . . . . . . . . . 32 95 12.1.2. MPSP for TLS TM-Security Model . . . . . . . . . . . . 32 96 12.1.3. MIB Module for TLS Security . . . . . . . . . . . . . 32 97 12.2. DTLS/UDP Transport Mapping Security Model . . . . . . . . 32 98 12.2.1. tmStateReference for DTLS . . . . . . . . . . . . . . 33 99 12.3. SASL Transport Mapping Security Model . . . . . . . . . . 34 100 12.3.1. tmStateReference for SASL DIGEST-MD5 . . . . . . . . 34 101 13. The TMSM MIB Module . . . . . . . . . . . . . . . . . . . . . 35 102 13.1. Structure of the MIB Module . . . . . . . . . . . . . . . 35 103 13.1.1. Textual Conventions . . . . . . . . . . . . . . . . . 35 104 13.1.2. The tmsmStats Subtree . . . . . . . . . . . . . . . . 35 105 13.1.3. The tmsmsSession Subtree . . . . . . . . . . . . . . . 35 106 13.1.4. The Notifications Subtree . . . . . . . . . . . . . . 35 107 13.2. Relationship to Other MIB Modules . . . . . . . . . . . . 36 108 13.2.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 36 109 13.2.2. MIB Modules Required for IMPORTS . . . . . . . . . . . 36 110 14. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 36 111 15. Implementation Considerations . . . . . . . . . . . . . . . . 42 112 15.1. Applications that Benefit from Sessions . . . . . . . . . 42 113 15.2. Applications that Suffer from Sessions . . . . . . . . . . 43 114 15.2.1. Troubleshooting . . . . . . . . . . . . . . . . . . . 43 115 16. Security Considerations . . . . . . . . . . . . . . . . . . . 43 116 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 117 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 118 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 119 19.1. Normative References . . . . . . . . . . . . . . . . . . . 45 120 19.2. Informative References . . . . . . . . . . . . . . . . . . 47 121 Appendix A. Questions about msgFlags: . . . . . . . . . . . . . . 47 122 A.1. msgFlags versus actual security . . . . . . . . . . . . . 48 123 Appendix B. Parameter Table . . . . . . . . . . . . . . . . . . . 49 124 B.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 49 125 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 50 126 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 51 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 128 Intellectual Property and Copyright Statements . . . . . . . . . . 51 130 1. Introduction 132 This document describes a Transport Mapping Security Model (TMSM) 133 subsystem for the Simple Network Management Protocol (SNMP) 134 architecture defined in [RFC3411]. This document identifies and 135 discusses some key aspects that need to be considered for any 136 transport-mapping-based security model for SNMP. 138 1.1. The Internet-Standard Management Framework 140 For a detailed overview of the documents that describe the current 141 Internet-Standard Management Framework, please refer to section 7 of 142 RFC 3410 [RFC3410]. 144 Managed objects are accessed via a virtual information store, termed 145 the Management Information Base or MIB. MIB objects are generally 146 accessed through the Simple Network Management Protocol (SNMP). 147 Objects in the MIB are defined using the mechanisms defined in the 148 Structure of Management Information (SMI). This memo specifies a MIB 149 module that is compliant to the SMIv2, which is described in STD 58, 150 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 151 [RFC2580]. 153 1.2. Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 Some points requiring further WG research and discussion are 160 identified by [discuss] markers in the text. Some points requiring 161 further editing by the editors are marked [todo] in the text. 163 1.3. Motivation 165 There are multiple ways to secure one's home or business, but they 166 largely boil down to a continuum of alternatives. Let's consider 167 three general approaches. In the first approach, an individual could 168 buy a gun, learn to use it, and sit on your front porch waiting for 169 intruders. In the second approach, one could hire an employee with a 170 gun, schedule the employee, position the employee to guard what you 171 want protected, hire a second guard to cover if the first gets sick, 172 and so on. In the third approach, you could hire a security company, 173 tell them what you want protected, and they could hire employees, 174 train them, buy the guns, position the guards, schedule the guards, 175 send a replacement when a guard cannot make it, etc., thus providing 176 the security you want, with no significant effort on your part other 177 than identifying requirements and verifying the quality of the 178 service being provided. 180 The User-based Security Model (USM) as defined in [RFC3414] largely 181 uses the first approach - it provides its own security. It utilizes 182 existing mechanisms (MD5=the gun), but provides all the coordination. 183 USM provides for the authentication of a principal, message 184 encryption, data integrity checking, timeliness checking, etc. 186 USM was designed to be independent of other existing security 187 infrastructures. USM therefore requires a separate user and key 188 management infrastructure. Operators have reported that deploying 189 another user and key management infrastructure in order to use SNMPv3 190 is a deterrent to deploying SNMPv3. It is possible but difficult to 191 define external mechanisms that handle the distribution of keys for 192 use by the USM approach. 194 A solution based on the second approach might use a USM-compliant 195 architecture, but combine the authentication mechanism with an 196 external mechanism, such as RADIUS [RFC2865], to provide the 197 authentication service. It might be possible to utilize an external 198 protocol to encrypt a message, to check timeliness, to check data 199 integrity, etc. It is difficult to cobble together a number of 200 subcontracted services and coordinate them however, because it is 201 difficult to build solid security bindings between the various 202 services, and potential for gaps in the security is significant. 204 A solution based on the third approach might utilize one or more 205 lower-layer security mechanisms to provide the message-oriented 206 security services required. These would include authentication of 207 the sender, encryption, timeliness checking, and data integrity 208 checking. There are a number of IETF standards available or in 209 development to address these problems through security layers at the 210 transport layer or application layer, among them TLS [RFC2246], SASL 211 [RFC2222], and SSH [RFC4251]. 213 From an operational perspective, it is highly desirable to use 214 security mechanisms that can unify the administrative security 215 management for SNMPv3, command line interfaces (CLIs) and other 216 management interfaces. The use of security services provided by 217 lower layers is the approach commonly used for the CLI, and is also 218 the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. 220 This document proposes a Transport Mapping Security Model (TMSM) 221 subsystem, as an extension of the RFC3411 architecture, that allows 222 security to be provided by an external protocol connected to the SNMP 223 engine through an SNMP transport-mapping. Such a TMSM would then 224 enable the use of existing security mechanisms such as (TLS) 225 [RFC2246] or SSH [RFC4251] within the RFC3411 architecture. 227 There are a number of Internet security protocols and mechanisms that 228 are in wide spread use. Many of them try to provide a generic 229 infrastructure to be used by many different application layer 230 protocols. The motivation behind TMSM is to leverage these protocols 231 where it seems useful. 233 There are a number of challenges to be addressed to map the security 234 provided by a secure transport into the SNMP architecture so that 235 SNMP continues to work without any surprises. These challenges are 236 discussed in detail in this document. For some key issues, design 237 choices are discussed that may be made to provide a workable solution 238 that meets operational requirements and fits into the SNMP 239 architecture defined in [RFC3411] . 241 2. Requirements of a Transport Mapping Security Model 243 2.1. Security Requirements 245 Transport mapping security protocols SHOULD ideally provide the 246 protection against the following message-oriented threats [RFC3411]: 248 1. modification of information 249 2. masquerade 250 3. message stream modification 251 4. disclosure 253 According to [RFC3411], it is not required to protect against denial 254 of service or traffic analysis. 256 2.1.1. Security Protocol Requirements 258 There are a number of standard protocols that could be proposed as 259 possible solutions within the TMSM framework. Some factors should be 260 considered when selecting a protocol for use within this framework. 262 Using a protocol in a manner for which it was not designed has 263 numerous problems. The advertised security characteristics of a 264 protocol may depend on its being used as designed; when used in other 265 ways, it may not deliver the expected security characteristics. It 266 is recommended that any proposed model include a discussion of the 267 applicability statement of the protocols to be used. 269 A protocol used for the TMSM framework should ideally require no 270 modifications to the protocol. Modifying the protocol may change its 271 security characteristics in ways that would impact other existing 272 usages. If a change is necessary, the change should be an extension 273 that has no impact on the existing usages. It is recommended that 274 any proposed model include a discussion of potential impact on other 275 usages of the protocol. 277 It has been a long-standing requirement that SNMP be able to work 278 when the network is unstable, to enable network troubleshooting and 279 repair. The UDP approach has been considered to meet that need well, 280 with an assumption that getting small messages through, even if out 281 of order, is better than getting no messages through. There has been 282 a long debate about whether UDP actually offers better support than 283 TCP when the underlying IP or lower layers are unstable. There has 284 been recent discussion of whether operators actually use SNMP to 285 troubleshoot and repair unstable networks. 287 There has been discussion of ways SNMP could be extended to better 288 support management/monitoring needs when a network is running just 289 fine. Use of a TCP transport, for example, could enable larger 290 message sizes and more efficient table retrievals. 292 TMSM models MUST be able to coexist with other protocol models, and 293 may be designed to utilize either TCP or UDP, depending on the 294 transport. 296 2.2. Session Requirements 298 Throughout this document, the term session is used. Some underlying 299 secure transports will have a notion of session. Some underlying 300 secure transports might enable the use of channels or other session- 301 like thing. In this document the term session refers to an 302 association between two SNMP engines, that permits the secure 303 transmission of one or more SNMP messages within the lifetime of the 304 session. How the session is actually established, opened, closed, or 305 maintained is specific to a particular security model. 307 Sessions are not part of the SNMP architecture described in 308 [RFC3411], but are considered desirable because the cost of 309 authentication can be amortized over potentially many transactions. 311 It is important to note that the architecture described in [RFC3411] 312 does not include a session selector in the Abstract Service 313 Interfaces, and neither is that done for this architectural 314 extension, so an SNMP application cannot select the session except by 315 passing a unique combination of securityName, securityModel, and 316 securityLevel. 318 All TMSM-based security models should discuss the impact of sessions 319 on SNMP usage, including how to establish/open a TMSM session (i.e. 320 how it maps to the concepts of session-like things of the underlying 321 protocol), how to behave when a TMSM session cannot be established, 322 how to close a TMSM session (and the underlying protocol equivalent) 323 properly, how to behave when a TMSM session is closed improperly, the 324 session security properties, session establishment overhead, and 325 session maintenance overhead. 327 To reduce redundancy, this document will discuss aspects that are 328 expected to be common to all TMSM-based security model sessions. 330 2.2.1. Session Establishment Requirements 332 [todo] contributions welcome. 334 2.2.2. Session Maintenance Requirements 336 [todo] contributions welcome. 338 2.2.3. Message security versus session security 340 A TMSM session is associated with state information that is 341 maintained for its lifetime. This state information allows for the 342 application of various security services to TMSM-based security 343 models. Cryptographic keys established at the beginning of the 344 session SHOULD be used to provide authentication, integrity checking, 345 and encryption services for data that is communicated during the 346 session. The cryptographic protocols used to establish keys for a 347 TMSM-based security model session SHOULD ensure that fresh new 348 session keys are generated for each session. If each session uses 349 new session keys, then messages cannot be replayed from one session 350 to another. In addition sequence information MAY be maintained in 351 the session which can be used to prevent the replay and reordering of 352 messages within a session. 354 A TMSM session will typically have a single securityName and 355 securityLevel associated with it. If an exchange between 356 communicating engines would require a different securityLevel or 357 would be on behalf of a different securityName, then another session 358 would be needed. An immediate consequence of this is that 359 implementations should be able to maintain some reasonable number of 360 concurrent sessions. 362 For TMSM models, securityName is typically specified during session 363 setup, and associated with the session identifier. 365 SNMPv3 was designed to support multiple levels of security, 366 selectable on a per-message basis by an SNMP application, because 367 there is not much value in using encryption for a Commander Generator 368 to poll for non-sensitive performance data on thousands of interfaces 369 every ten minutes; the encryption adds significant overhead to 370 processing of the messages. 372 Some TMSM-based security models MAY support only specific 373 authentication and encryption services, such as requiring all 374 messages to be carried using both authentication and encryption, 375 regardless of the security level requested by an SNMP application. 377 Some security models may use an underlying transport that provides a 378 per-message requested level of authentication and encryption 379 services. For example, if a session is created as 'authPriv', then 380 keys for encryption could still be negotiated once at the beginning 381 of the session. But if a message is presented to the session with a 382 security level of authNoPriv, then that message could simply be 383 authenticated and not encrypted within the same transport session. 384 Whether this is possible depends on the security model and the secure 385 transport used. 387 If the underlying transport layer security was configurable on a per- 388 message basis, a TMSM-based security model could have a security- 389 model-specific MIB module with configurable maxSecurityLevel and a 390 minSecurityLevel objects to identify the range of possible levels. A 391 session's maxSecurityLevel would identify the maximum security it 392 could provide, and a session created with a minSecurityLevel of 393 authPriv would reject an attempt to send an authNoPriv message. The 394 elements of procedure of the security model would need to describe 395 the procedures to enable this determination. 397 For security models that do not support variable security services in 398 one session, multiple sessions could be established, with different 399 security levels, and for every packet the SNMP engine could select 400 the appropriate session based on the requested securityLevel. Some 401 SNMP entities are resource-constrained. Adding sessions increases 402 the need for resources, but so does encrypting unnecessarily. 403 Designers of security models should consider the tradeoffs for 404 resource-constrained devices. 406 2.3. Architectural Modularity Requirements 408 SNMP version 3 (SNMPv3) is based on a modular architecture (described 409 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 410 standards over time, and to minimize side effects between subsystems 411 when changes are made. This architecture includes a Security 412 Subsystem which is responsible for realizing security services. 414 In SNMPv2, there were many problems of side effects between 415 subsystems caused by the manipulation of MIB objects, especially 416 those related to authentication and authorization, because many of 417 the parameters were stored in shared MIB objects, and different 418 models and protocols could assign different values to the objects. 419 Contributors assumed slightly different shades of meaning depending 420 on the models and protocols being used. As the shared MIB module 421 design was modified to accommodate a specific model, other models 422 which used the same MIB objects were broken. 424 Abstract Service Interfaces (ASIs) were developed to pass model- 425 independent parameters. The models were required to translate from 426 their model-dependent formats into a model-independent format, 427 defined using model-independent semantics, which would not impact 428 other models. 430 Parameters have been provided in the ASIs to pass model-independent 431 information about the authentication that has been provided. These 432 parameters include a model-independent identifier of the security 433 "principal", the security model used to perform the authentication, 434 and which SNMP-specific security features were applied to the message 435 (authentication and/or privacy). 437 The design of a transport mapping security model must abide the goals 438 of the RFC3411 architecture defined in [RFC3411]. To that end, this 439 transport mapping security model proposal focuses on a modular 440 subsystem that can be advanced through the standards process 441 independently of other proposals, and independent of other subsystems 442 as much as possible. 444 There has been some discussion of maintaining multiple sessions for 445 different security levels or for different applications. The ability 446 to have an application select different sessions or connections on a 447 per-message basis would likely require a modification to the SNMP 448 architecture to provide new ASIs, which is out of scope for this 449 document. 451 [discuss] I am not sure whether the previous paragraph is still 452 correct - I think we need to solve at least some of the session 453 problem space. 455 IETF standards typically require one mandatory-to-implement solution, 456 with the capability of adding new security mechanisms in the future. 457 Any transport mapping security model should define one minimum- 458 compliance mechanism, preferably one which is already widely deployed 459 within the transport layer security protocol used. 461 The TMSM subsystem is designed as an architectural extension that 462 permits additional transport security protocols to be "plugged into" 463 the RFC3411 architecture, supported by corresponding transport- 464 security-aware transport mapping models. 466 The RFC3411 architecture, and the USM approach, assume that a 467 security model is called by a message-processing model and will 468 perform multiple security functions. The TMSM approach performs 469 similar functions but performs them in different places within the 470 architecture, so we need to distinguish the two locations for 471 security processing. 473 Transport mapping security is by its very nature a security layer 474 which is plugged into the RFC3411 architecture between the transport 475 layer and the message dispatcher. Conceptually, transport mapping 476 security processing will be called from within the Transport Mapping 477 functionality of an SNMP engine dispatcher to perform the translation 478 of transport security parameters to/from security-model-independent 479 parameters. This transport mapping security processor will be 480 referred to in this document as TMSP. 482 Additional functionality may be performed as part of the message 483 processing function, i.e. in the security subsystem of the RFC3411 484 architecture. This document will refer to message processor's 485 security processor as the MPSP. 487 Thus a TMSM is composed of both a TPSP and an MPSP. 489 +------------------------------+ 490 | Network | 491 +------------------------------+ 492 ^ ^ ^ 493 | | | 494 v v v 495 +-----+ +-----+ +-------+ 496 | UDP | | TCP | . . . | other | 497 +-----+ +-----+ +-------+ 498 ^ ^ ^ 499 | | | 500 v v v 501 +-----+ +-----+ +-------+ 502 | SSH | | TLS | . . . | other | 503 +-----+ +-----+ +-------+ (traditional SNMP agent) 504 +-------------------------------------------------------------------+ 505 | ^ | 506 | | | 507 | Dispatcher v | 508 | +-------------------+ | 509 | | Transport | +--------------+ | 510 | | Mapping |<---> | TMSM | | 511 | | (e.g., RFC 3417) | | TMSP | | 512 | | | +--------------+ | 513 | | | | 514 | | | +---------------------+ +----------------+ | 515 | | | | Message Processing | | Security | | 516 | | | | Subsystem | | Subsystem | | 517 | | | | +------------+ | | | | 518 | | | | +->| v1MP * |<--->| +------------+ | | 519 | | | | | +------------+ | | | Other | | | 520 | | | | | +------------+ | | | Security | | | 521 | | | | +->| v2cMP * |<--->| | Model | | | 522 | | Message | | | +------------+ | | +------------+ | | 523 | | Dispatcher <--------->| +------------+ | | +------------+ | | 524 | | | | +->| v3MP * |<--->| | TMSM | | | 525 | | | | | +------------+ | | | MPSP | | | 526 | | PDU Dispatcher | | | +------------+ | | | | | | 527 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 528 | ^ | +------------+ | | | | 529 | | +---------------------+ +----------------+ | 530 | v | 531 | +-------+-------------------------+---------------+ | 532 | ^ ^ ^ | 533 | | | | | 534 | v v v | 535 | +-------------+ +---------+ +--------------+ +-------------+ | 536 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 537 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 538 | | application | | | | applications | | application | | 539 | +-------------+ +---------+ +--------------+ +-------------+ | 540 | ^ ^ | 541 | | | | 542 | v v | 543 | +----------------------------------------------+ | 544 | | MIB instrumentation | SNMP entity | 545 +-------------------------------------------------------------------+ 547 2.3.1. USM and the RFC3411 Architecture 549 The following diagrams illustrate the difference in the security 550 processing done by the USM model and the security processing done by 551 a TMSM model. 553 The USM security model is encapsulated by the messaging model, 554 because the messaging model needs to perform the following steps (for 555 incoming messages) 556 1) decode the ASN.1 (messaging model) 557 2) determine the SNMP security model and parameters (messaging model) 558 3) decrypt the encrypted portions of the message (security model) 559 4) translate parameters to model-independent parameters (security 560 model) 561 5) determine which application should get the decrypted portions 562 (messaging model), and 563 6) pass on the decrypted portions with model-independent parameters. 565 The USM approach uses SNMP-specific message security and parameters. 567 | -----------------------------------------------| 568 | transport layer | 569 | -----------------------------------------------| 570 ^ 571 | 572 v 573 -------------------------------------------------- 574 | -----------------------------------------------| 575 | | transport mapping | 576 | -----------------------------------------------| 577 | ^ 578 | | 579 | v 580 | --------------------------------------------- | 581 | --------------------- ------------------ | 582 | SNMP messaging <--> | decryption + | | 583 | | translation | | 584 | --------------------- ------------------ | 585 | ^ 586 | | 587 | v 588 | --------------------- ------------------ | 589 | | SNMP applications | <--> | access control | | 590 | --------------------- ------------------ | 592 | --------------------------------------------- | 594 2.3.2. TMSM and the RFC3411 Architecture 596 In the TMSM approach, the order of the steps differ and may be 597 handled by different subsystems: 599 1) decrypt the encrypted portions of the message (transport layer) 600 2) determine the SNMP security model and parameters (transport 601 mapping) 602 3*) translate parameters to model-independent parameters (transport 603 mapping) 604 4) decode the ASN.1 (messaging model) 605 5) determine which application should get the decrypted portions 606 (messaging model) 607 6*) translate parameters to model-independent parameters (security 608 model) 609 7) pass on the decrypted portions with model-independent security 610 parameters 612 This is largely based on having non-SNMP-specific message security 613 and parameters. The transport mapping model might provide the 614 translation from e.g., an SSH user name to the securityName in step 615 3, OR the SSH user might be passed to the messaging model to pass to 616 a TMSM security model to do the translation in step 6, if the WG 617 decides all translations should use the same translation table (e.g., 618 the USM MIB). 620 | -----------------------------------------------| 621 | ------------------ | 622 | transport layer <--> | decryption | | 623 | ------------------ | 624 | -----------------------------------------------| 625 ^ 626 | 627 v 628 -------------------------------------------------- 629 | -----------------------------------------------| 630 | ------------------ | 631 | transport mapping <--> | translation* | | 632 | ------------------ | 633 | -----------------------------------------------| 634 | ^ 635 | | 636 | v 637 | --------------------------------------------- | 638 | ------------------ | 639 | SNMP messaging <--> | translation* | | 640 | ------------------ | 641 | --------------------- ------------------ | 642 | ^ 643 | | 644 | v 645 | --------------------- ------------------ | 646 | | SNMP applications | <--> | access control | | 647 | --------------------- ------------------ | 649 | --------------------------------------------- | 651 2.4. Passing Messages between Subsystems 653 RFC3411 defines ASIs that describe the passing of messages between 654 subsystem within an engine, and the parameters which are expected to 655 be passed between the subsystems. The ASIs generally pass model- 656 independent information. 658 A TMSM model will establish an encrypted tunnel between the transport 659 mappings of two SNMP engines. One transport mapping security model 660 instance encrypts all messages, and the other transport mapping 661 security model instance decrypts the messages. 663 After the transport layer tunnel is established, then SNMP messages 664 can conceptually be sent through the tunnel from one SNMP message 665 dispatcher to another SNMP message dispatcher. Once the tunnel is 666 established, multiple SNMP messages may be able to be passed through 667 the same tunnel. 669 Within an engine, outgoing SNMP messages are passed unencrypted from 670 the message dispatcher to the transport mapping, and incoming 671 messages are passed unencrypted from the transport mapping to the 672 message dispatcher. 674 2.5. Security Parameter Passing Requirement 676 RFC3411 section 4 describes primitives to describe the abstract 677 service interfaces used to conceptually pass information between the 678 various subsystems, models and applications within the architecture. 680 The security parameters include a model-independent identifier of the 681 security "principal", the security model used to perform the 682 authentication, and which SNMP-specific security services were 683 (should be) applied to the message (authentication and/or privacy). 685 In the RFC3411 architecture, the messaging model must unpack SNMP- 686 specific security parameters from the message before calling a 687 security model to authenticate and decrypt an incoming message, 688 perform integrity checking, and translate model-specific security 689 parameters into model-independent parameters. In the TMSM approach, 690 the security-model specific parameters are not all carried in the 691 SNMP message, and can be determined from the transport layer by the 692 transport mapping, before the message processing begins. 694 [discuss] For outgoing messages, it is necessary to have an MPSP 695 because it is the MPSP that actually creates the message from its 696 component parts. Does the MPSP need to know the transport address or 697 the actual transport security capabilities, or can this be handled in 698 the TMSP, given the model-independent (and message-version- 699 independent) parameters? Are there any security services provided by 700 the MPSP for an outgoing message? 702 [discuss] For incoming messages, is there security functionality that 703 can only be handled after the message version is known, such as the 704 comparison of transport security capabilities and msgFlags? Does 705 that functionality need to know the transport address and session or 706 just the model-independent security parameters (securityName, model, 707 level)? Are there any SNMP-specific parameters that need to be 708 unpacked from the message for MPSP handling? msgFlags, securityLevel, 709 etc.? 711 The RFC3411 architecture has no ASI parameters for passing security 712 information between the transport mapping and the dispatcher, and 713 between the dispatcher and the message processing model. If there is 714 a need to have an MPSP called from the message processing model to, 715 for example, verify that msgFlags and the transport security are 716 consistent, then it will be necessary to pass the model-independent 717 security parameters from the TPSP through to the MPSP. 719 There are four approaches that could be used for passing information 720 between the TMSP and an MPSP. 721 1. one could define an ASI to supplement the existing ASIs, or 722 2. the TMSM could add a header to encapsulate the SNMP message, 723 3. the TMSM could utilize fields already defined in the existing 724 SNMPv3 message, or 725 4. the TMSM could pass the information in an implementation-specific 726 cache or via a MIB module. 728 2.5.1. Define an Abstract Service Interface 730 Abstract Service Interfaces (ASIs) [RFC3411] are defined by a set of 731 primitives that specify the services provided and the abstract data 732 elements that are to be passed when the services are invoked. 733 Defining additional ASIs to pass the security and transport 734 information from the transport mapping to a messaging security model 735 has the advantage of being consistent with existing RFC3411/3412 736 practice, and helps to ensure that any TMSM proposals pass the 737 necessary data, and do not cause side effects by creating model- 738 specific dependencies between itself and other models or other 739 subsystems other than those that are clearly defined by an ASI. 741 2.5.2. Using an Encapsulating Header 743 A header could encapsulate the SNMP message to pass necessary 744 information from the TMSP to the dispatcher and then to a messaging 745 security model. The message header would be included in the 746 wholeMessage ASI parameter, and would be removed by a corresponding 747 messaging model. This would imply the (one and only) messaging 748 dispatcher would need to be modified to determine which SNMP message 749 version was involved, and a new message processing model would need 750 to be developed that knew how to extract the header from the message 751 and pass it to the MPSP. 753 2.5.3. Modifying Existing Fields in an SNMP Message 755 [RFC3412] describes the SNMPv3 message, which contains fields to pass 756 security related parameters. The TMSM could use these fields in an 757 SNMPv3 message, or comparable fields in other message formats to pass 758 information between transport mapping security models in different 759 SNMP engines, and to pass information between a transport mapping 760 security model and a corresponding messaging security model. 762 If the fields in an incoming SNMPv3 message are changed by the TMSP 763 before passing it to the MPSP, then the TMSP will need to decode the 764 ASN.1 message, modify the fields, and re-encode the message in ASN.1 765 before passing the message on to the message dispatcher or to the 766 transport layer. This would require an intimate knowledge of the 767 message format and message versions so the TMSP knew which fields 768 could be modified. This would seriously violate the modularity of 769 the architecture. 771 2.5.4. Using a Cache 773 A cache mechanism could be used, into which the TMSP puts information 774 about the security applied to an incoming message, and an MPSP 775 extracts that information from the cache. Given that there may be 776 multiple TM-security caches, a cache ID would need to be passed 777 through an ASI so the MPSP knows which cache of information to 778 consult. 780 The cache reference could be thought of as an additional parameter in 781 the ASIs between the transport mapping and the messaging security 782 model. The RFC3411 ASIs would not need to be changed since the 783 SNMPv3 WG expected that additional parameters could be passed for 784 value-add features of specific implementations. 786 This approach does create dependencies between a model-specific TPSP 787 and a corresponding specific MPSP. If a TMSM-model-independent ASI 788 parameter is passed, this approach would be consistent with the 789 securityStateReference cache already being passed around in the ASI. 791 This document will describe a cache-based approach. 793 2.6. Architectural Requirements for Access Control 795 2.6.1. securityName Binding 797 For SNMP access control to function properly, the security mechanism 798 must establish a securityModel identifier, a securityLevel, and a 799 securityName, which is the security model independent identifier for 800 a principal. The SNMPv3 message processing architecture subsystem 801 relies on a security model, such as USM, to play a role in security 802 that goes beyond protecting the message - it provides a mapping 803 between the USM-specific principal to a security-model independent 804 securityName which can be used for subsequent processing, such as for 805 access control. 807 The TMSM is a two-stage security model, with a transport mapping 808 security process (TMSP) and a message processing security process 809 (MPSP). Depending on the design of the specific TMSM model, i.e. 811 which transport layer protocol is used, different features might be 812 provided by the TMSP or by the MPSP. For example, the translation 813 from a mechanism-specific authenticated identity to a securityName 814 might be done by the TMSP or by the MPSP. 816 [discuss] It may be possible to define a consistent division of 817 stages regardless of the transport layer protocol used, and a 818 consistent division of functionality would be preferred. 820 The SNMP architecture distinguishes between messages with no 821 authentication and no privacy (noAuthNoPriv), authentication without 822 privacy (authNoPriv) and authentication with privacy (authPriv). 823 Hence, the authentication of a transport layer identity plays an 824 important role and must be considered by any TMSM, and user 825 authentication must be available via the transport layer security 826 protocol. 828 If the type of authentication provided by the transport layer (e.g. 829 host-based or anonymous) is considered adequate to secure and/or 830 encrypt the message, but inadequate to provide the desired 831 granularity of access control (e.g. user-based), a second 832 authentication, e.g. one provided by a AAA server, may be used to 833 provide the authentication identity which is bound to the 834 securityName. This approach would require a good analysis of the 835 potential for man-in-the-middle attacks or masquerade possibilities. 837 2.6.2. Separation of Authentication and Authorization 839 A TMSM security model should take care to not violate the separation 840 of authentication and authorization in the RFC3411 architecture.. 841 The isAccessAllowed() primitive is used for passing security-model 842 independent parameters between the subsystems of the architecture. 844 Mapping of (securityModel, securityName) to an access control policy 845 should be handled within the access control subsystem, not the 846 security subsystem, to be consistent with the modularity of the 847 RFC3411 architecture. This separation was a deliberate decision of 848 the SNMPv3 WG, to allow support for authentication protocols which 849 did not provide authorization capabilities, and to support 850 authorization schemes, such as VACM, that do not perform their own 851 authentication. 853 An authorization model MAY require authentication by certain 854 securityModels and a minimum securityLevel to allow access to the 855 data. 857 TMSM is an enhancement for the SNMPv3 privacy and authentication 858 provisions, but it is not a significant improvement for the 859 authorization needs of SNMPv3. TMSM provides all the model- 860 independent parameters for the isAccessAllowed() primitive [RFC3411]. 862 TMSM does not specify how the securityModel and securityName could be 863 dynamically mapped to a VACM-style groupName. The mapping of 864 (securityModel, securityName) to a groupName is a VACM-specific 865 mechanism for naming an access control policy, and for tying the 866 named policy to the addressing capabilities of the data modeling 867 language (e.g. SMIv2 [RFC2578]), the operations supported, and other 868 factors. Providing a binding outside the Access Control subsystem 869 might create dependencies that could make it harder to develop 870 alternate models of access control, such as one built on UNIX groups, 871 Windows domains, XML hierarchies, or task-based controls. The 872 preferred approach is to pass the model-independent security 873 parameters via the isAccessAllowed() ASI, and perform the mapping 874 within the access control model. 876 To provide support for protocols which simultaneously send 877 information for authentication and authorization, such as RADIUS 878 [RFC2865], model-specific authorization information MAY be cached or 879 otherwise made available to the access control subsystem, e.g. via a 880 MIB table similar to the vacmSecurityToGroupTable, so the access 881 control subsystem can create an appropriate binding between the 882 model-independent securityModel and securityName and a model-specific 883 access control policy. This may be highly undesirable, however, if 884 it creates a dependency between a security model and an access 885 control model, just as it is undesirable that the TMSM approach 886 creates a dependency between a TMSP and an MPSP. 888 2.7. Requirements for Notifications 890 [todo] cleanup this section 892 RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated 893 by notification originators in case there is no currently established 894 connection that can be used to send the notification. Following this 895 approach with SSH would require to provision authentication 896 credentials on the agent so that agents can successfully authenticate 897 to a notification receiver. There might be other approaches, like 898 the reuse of manager initiated secure transport connections for 899 notifications. There is some text in Appendix A in RFC 3430 which 900 captures some of these discussions when RFC 3430 was written. 902 [todo] merge this text and text from RFC 3430 into the section 903 dealing with sessions? This seems to be the right place for this 904 discussion. 906 3. Scenario Diagrams 908 RFC3411 section 4.6 provides scenario diagrams to illustrate how an 909 outgoing message is created, and how an incoming message is 910 processed. Both diagrams are incomplete, however. In section 4.6.1, 911 the diagram doesn't show the ASI for sending an SNMP request to the 912 network or receiving an SNMP response message from the network. In 913 section 4.6.2, the diagram doesn't illustrate the interfaces required 914 to receive an SNMP message from the network, or to send an SNMP 915 message to the network. 917 3.1. Command Generator or Notification Originator 919 This diagram from RFC3411 4.6.1 shows how a Command Generator or 920 Notification Originator application [RFC3413]requests that a PDU be 921 sent, and how the response is returned (asynchronously) to that 922 application. 924 Command Dispatcher Message Security 925 Generator | Processing Model 926 | | Model | 927 | sendPdu | | | 928 |------------------->| | | 929 | | prepareOutgoingMessage | | 930 : |----------------------->| | 931 : | | generateRequestMsg | 932 : | |-------------------->| 933 : | | | 934 : | |<--------------------| 935 : | | | 936 : |<-----------------------| | 937 : | | | 938 : |------------------+ | | 939 : | Send SNMP | | | 940 : | Request Message | | | 941 : | to Network | | | 942 : | v | | 943 : : : : : 944 : : : : : 945 : : : : : 946 : | | | | 947 : | Receive SNMP | | | 948 : | Response Message | | | 949 : | from Network | | | 950 : |<-----------------+ | | 951 : | | | 952 : | prepareDataElements | | 953 : |----------------------->| | 954 : | | processIncomingMsg | 955 : | |-------------------->| 956 : | | | 957 : | |<--------------------| 958 : | | | 959 : |<-----------------------| | 960 | processResponsePdu | | | 961 |<-------------------| | | 962 | | | | 964 3.2. Command Responder 966 This diagram shows how a Command Responder or Notification Receiver 967 application registers for handling a pduType, how a PDU is dispatched 968 to the application after an SNMP message is received, and how the 969 Response is (asynchronously) send back to the network. 971 Command Dispatcher Message Security 972 Responder | Processing Model 973 | | Model | 974 | | | | 975 | registerContextEngineID | | | 976 |------------------------>| | | 977 |<------------------------| | | | 978 | | Receive SNMP | | | 979 : | Message | | | 980 : | from Network | | | 981 : |<-------------+ | | 982 : | | | 983 : |prepareDataElements | | 984 : |------------------->| | 985 : | | processIncomingMsg | 986 : | |------------------->| 987 : | | | 988 : | |<-------------------| 989 : | | | 990 : |<-------------------| | 991 | processPdu | | | 992 |<------------------------| | | 993 | | | | 994 : : : : 995 : : : : 996 | returnResponsePdu | | | 997 |------------------------>| | | 998 : | prepareResponseMsg | | 999 : |------------------->| | 1000 : | |generateResponseMsg | 1001 : | |------------------->| 1002 : | | | 1003 : | |<-------------------| 1004 : | | | 1005 : |<-------------------| | 1006 : | | | 1007 : |--------------+ | | 1008 : | Send SNMP | | | 1009 : | Message | | | 1010 : | to Network | | | 1011 : | v | | 1013 4. Abstract Service Interfaces 1015 The OUT parameters of the prepareOutgoingMessage() ASI are used to 1016 pass information from the message processing model to the dispatcher 1017 and on to the transport mapping: 1019 statusInformation = -- success or errorIndication 1020 prepareOutgoingMessage( 1021 IN transportDomain -- transport domain to be used 1022 IN transportAddress -- transport address to be used 1023 IN messageProcessingModel -- typically, SNMP version 1024 IN securityModel -- Security Model to use 1025 IN securityName -- on behalf of this principal 1026 IN securityLevel -- Level of Security requested 1027 IN contextEngineID -- data from/at this entity 1028 IN contextName -- data from/in this context 1029 IN pduVersion -- the version of the PDU 1030 IN PDU -- SNMP Protocol Data Unit 1031 IN expectResponse -- TRUE or FALSE 1032 IN sendPduHandle -- the handle for matching 1033 -- incoming responses 1034 OUT destTransportDomain -- destination transport domain 1035 OUT destTransportAddress -- destination transport address 1036 OUT outgoingMessage -- the message to send 1037 OUT outgoingMessageLength -- its length 1038 ) 1040 5. TMSM Abstract Service Interfaces 1042 A set of abstract service interfaces have been defined within this 1043 document to describe the conceptual data flows between the Transport 1044 Mapping Security Models and adjacent components in the system.. 1046 The SendMessage ASI is used to pass a message from the Dispatcher to 1047 the transport mapping security model subsystem for sending. 1049 statusInformation sendMessage( 1050 IN destTransportDomain -- transport domain to be used 1051 IN destTransportAddress -- transport address to be used 1052 IN outgoingMessage -- the message to send 1053 IN outgoingMessageLength -- its length 1054 IN tmStateReference -- 1055 OUT sessionID 1056 ) 1058 The RecvMessage ASI is used to pass a message from the transport 1059 mapping security model subsystem to the Dispatcher. 1061 statusInformation RecvMessage( 1062 IN destTransportDomain -- transport domain to be used 1063 IN destTransportAddress -- transport address to be used 1064 IN incomingMessage -- the message received 1065 IN incomingMessageLength -- its length 1066 OUT tmStateReference -- 1067 OUT sessionID 1068 ) 1070 The Transport Mapping Security Model provides the following 1071 primitives to pass data back and forth between the TMSM and specific 1072 TMSM-based security models, which provide the interface to the 1073 underlying secure transport service. Each TMSM-based security model 1074 should define the security-model-specific elements of procedure for 1075 the establishSession(), closeSession(), TxMessage(), and RxMessage() 1076 interfaces. 1078 statusInformation TxMessage( 1079 IN destTransportDomain -- transport domain to be used 1080 IN destTransportAddress -- transport address to be used 1081 IN outgoingMessage -- the message to send 1082 IN outgoingMessageLength -- its length 1083 IN tmStateReference -- 1084 OUT sessionID 1085 ) 1087 statusInformation RxMessage( 1088 IN destTransportDomain -- transport domain to be used 1089 IN destTransportAddress -- transport address to be used 1090 IN incomingMessage -- the message to send 1091 IN incomingMessageLength -- its length 1092 OUT tmStateReference -- 1093 ) 1095 statusInformation establishSession( 1096 IN transportDomain -- transport domain to be used 1097 IN transportAddress -- transport address to be used 1098 IN tmStateReference -- 1099 OUT sessionID 1100 ) 1102 statusInformation closeSession( 1103 IN sessionID 1104 ) 1106 6. Integration with the SNMPv3 Message Format 1108 TMSM proposals can use the SNMPv3 message format, defined in RFC3412, 1109 section 6. This section discusses how the fields could be reused. 1111 6.1. msgVersion 1113 For proposals that reuse the SNMPv3 message format, this field should 1114 contain the value 3. 1116 6.2. msgGlobalData 1118 The fields msgID and msgMaxSize are used identically for the TMSM 1119 models as for the USM model. 1121 The msgSecurityModel field should be set to a value from the 1122 SnmpSecurityModel enumeration [RFC3411] to identify the specific TMSM 1123 model. Each standards-track TMSM model should have an enumeration 1124 assigned by IANA. Each enterprise-specific security model should 1125 have an enumeration assigned following instructions in the 1126 description of the SnmpSecurityModel TEXTUAL-CONVENTION from RFC3411. 1128 The msgSecurityParameters field would carry security information 1129 required for message security processing. It is unclear whether this 1130 field would be useful or what parameters would be carried to support 1131 security, since message security is provided by an external process, 1132 and msgSecurityParameters are not used by the access control 1133 subsystem. 1135 RFC3412 defines two primitives, generateRequestMsg() and 1136 processIncomingMsg() which require the specification of an 1137 authoritative SNMP entity. [discuss] We need to discuss what the 1138 meaning of authoritative would be in a TMSM environment, whether the 1139 specific services provided in USM security from msgSecurityParameters 1140 still are needed, and how the Message Processing model provides this 1141 information to the security model via generateRequestMsg() and 1142 processIncomingMsg() primitives. RFC3412 specifies that "The data in 1143 the msgSecurityParameters field is used exclusively by the Security 1144 Model, and the contents and format of the data is defined by the 1145 Security Model. This OCTET STRING is not interpreted by the v3MP, 1146 but is passed to the local implementation of the Security Model 1147 indicated by the msgSecurityModel field in the message." 1149 The msgFlags have the same values for the TMSM models as for the USM 1150 model. "The authFlag and privFlag fields indicate the securityLevel 1151 that was applied to the message before it was sent on the wire." 1153 6.3. securityLevel and msgFlags 1155 For an outgoing message, msgFlags is the requested security for the 1156 message; if a TMSM cannot provide the requested securityLevel, the 1157 model MUST describe a standard behavior that is followed for that 1158 situation. If the TMSM cannot provide at least the requested level 1159 of security, the TMSM MUST discard the request and SHOULD notify the 1160 message processing model that the request failed. 1162 [discuss] how is yet to be determined, and may be model-specific or 1163 implementation-specific. 1165 For an outgoing message, if the TMSM is able to provide stronger than 1166 requested security, that may be acceptable. The transport layer 1167 protocol would need to indicate to the receiver what security has 1168 been applied to the actual message. To avoid the need to mess with 1169 the ASN.1 encoding, the SNMPv3 message carries the requested 1170 msgFlags, not the actual securityLevel applied to the message. If a 1171 message format other than SNMPv3 is used, then the new message may 1172 carry the more accurate securityLevel in the SNMP message. 1174 For an incoming message, the receiving TMSM knows what must be done 1175 to process the message based on the transport layer mechanisms. If 1176 the underlying transport security mechanisms for the receiver cannot 1177 provide the matching securityLevel, then the message should follow 1178 the standard behaviors for the transport security mechanism, or be 1179 discarded silently. 1181 Part of the responsibility of the TMSM is to ensure that the actual 1182 security provided by the underlying transport layer security 1183 mechanisms is configured to meet or exceed the securityLevel required 1184 by the msgFlags in the SNMP message. When the MPSP processes the 1185 incoming message, it should compare the msgFlags field to the 1186 securityLevel actually provided for the message by the transport 1187 layer security. If they differ, the MPSP should determine whether 1188 the changed securityLevel is acceptable. If not, it should discard 1189 the message. Depending on the model, the MPSP may issue a reportPDU 1190 with the XXXXXXX model-specific counter. 1192 7. The tmStateReference for Passing Security Parameters 1194 A tmStateReference is used to pass data between the TMSP and the 1195 MPSP, similar to the securityStateReference described in RFC3412. 1196 This can be envisioned as being appended to the ASIs between the TM 1197 and the MP or as being passed in an encapsulating header. 1199 The TMSP may provide only some aspects of security, and leave some 1200 aspects to the MPSP. tmStateReference should be used to pass any 1201 parameters, in a model- and mechanism-specific format, that will be 1202 needed to coordinate the activities of the TMSP and MPSP, and the 1203 parameters subsequently passed in securityStateReference. For 1204 example, the TMSP may provide privacy and data integrity and 1205 authentication and authorization policy retrievals, or some subset of 1206 these features, depending on the features available in the transport 1207 mechanisms. A field in tmStateReference should identify which 1208 services were provided for each received message by the TMSP, the 1209 securityLevel applied to the received message, the model-specific 1210 security identity, the session identifier for session based transport 1211 security, and so on. 1213 8. securityStateReference Cached Security Data 1215 From RFC3411: "For each message received, the Security Model caches 1216 the state information such that a Response message can be generated 1217 using the same security information, even if the Local Configuration 1218 Datastore is altered between the time of the incoming request and the 1219 outgoing response. 1221 A Message Processing Model has the responsibility for explicitly 1222 releasing the cached data if such data is no longer needed. To 1223 enable this, an abstract securityStateReference data element is 1224 passed from the Security Model to the Message Processing Model. The 1225 cached security data may be implicitly released via the generation of 1226 a response, or explicitly released by using the stateRelease 1227 primitive, as described in RFC3411 section 4.5.1." 1229 For the TMSM approach, the TMSP may need to provide information to 1230 the message processing model, such as the security-model-independent 1231 securityName, securityLevel, and securityModel parameters, and for 1232 responses, the messaging model may need to pass the parameters back 1233 to the TMSP. To differentiate what information needs to be provided 1234 to the message processing model by the TMSP, and vice-versa, this 1235 document will differentiate the tmStateReference provide by the TMSP 1236 from the securityStateReference provided by the MPSP. An 1237 implementation MAY use one cache and one reference to serve both 1238 functions, but an implementer must be aware of the cache-release 1239 issues to prevent the cache from being released before the transport 1240 mapping has had an opportunity to extract the information it needs. 1242 9. Prepare an Outgoing SNMP Message 1244 Following RFC3412, section 7.1, the SNMPv3 message processing model 1245 uses the generateResponseMsg() or generateRequestMsg() primitives, to 1246 call the MPSP. The message processing model, or the MPSP it calls, 1247 may need to put information into the tmStateReference cache for use 1248 by the TMSP, such as: 1249 tmSecurityStateReference - the unique identifier for the cached 1250 information 1251 tmTransportDomain 1252 tmTransportAddress 1253 tmSecurityModel - an indicator of which mechanisms to use 1254 tmSecurityName - a model-specific identifier of the security 1255 principal 1256 tmSecurityLevel - an indicator of which security services are 1257 requested 1258 and may contain additional information such as 1259 tmSessionID 1260 tmSessionKey 1261 tmSessionMsgID 1263 According to RFC3411, section 4.1.1, the application provides the 1264 transportDomain and transportAddress to the PDU dispatcher via the 1265 sendPDU() primitive. If we permit multiple sessions per 1266 transportAddress, then we would need to define how session 1267 identifiers get passed from the application to the PDU dispatcher 1268 (and then to the MP model). 1270 The SNMP over TCP Transport Mapping document [RFC3430] says that TCP 1271 connections can be recreated dynamically or kept for future use and 1272 actually leaves all that to the transport mapping. 1274 [discuss] we might define a new transportDomain and transportAddress, 1275 which includes the address and session identifier. For situations 1276 where a session has not yet been established, we could pass a 0x0000 1277 session identifier (or whatever) to indicate that a session should be 1278 established. Well, this won't work with the current TAddress 1279 definitions and is probably too ugly to do. 1281 We might have a MIB module that records the session information for 1282 subsequent use by the applications and other subsystems, or it might 1283 be passed in the tmStateReference cache. For notifications, I assume 1284 the SNMPv3 notification tables would be a place to find the address, 1285 but I'm not sure how to identify the presumably-dynamic session 1286 identifiers. The MIB module could identify whether the session was 1287 initiated by the remote engine or initiated by the current engine, 1288 and possibly assigned a purpose (incoming request/response or 1289 outgoing notifications). First we need to decide whether to handle 1290 notifications and requests in one or two (or more) sessions, which 1291 might depend on the transport protocol we choose (the same problem 1292 netconf faced). 1294 10. Prepare Data Elements from an Incoming SNMP Message 1296 For an incoming message, the TMSP will need to put information from 1297 the transport mechanisms used into the tmStateReference so the MPSP 1298 can extract the information and add it conceptually to the 1299 securityStateReference. 1301 The tmStateReference cache will likely contain at least the following 1302 information: 1303 tmStateReference - a unique identifier for the cached information 1304 tmSecurityStateReference - the unique identifier for the cached 1305 information 1306 tmTransportDomain 1307 tmTransportAddress 1308 tmSecurityModel - an indicator of which mechanisms to use 1309 tmSecurityName - a model-specific identifier of the security 1310 principal 1311 tmSecurityLevel - an indicator of which security services are 1312 requested 1313 tmAuthProtocol 1314 tmPrivProtocol 1315 and may contain additional information such as 1316 tmSessionID 1317 tmSessionKey 1318 tmSessionMsgID 1320 11. Notifications 1322 For notifications, if the cache has been released and then session 1323 closed, then the MPSP will request the TMSP to establish a session, 1324 populate the cache, and pass the securityStateReference to the MPSP. 1326 [discuss] We need to determine what state needs to be saved here. 1328 12. Transport Mapping Security Model Samples 1330 There are a number of standard protocols that could be proposed as 1331 possible solutions within the TMSM framework. Some factors should be 1332 considered when selecting a protocol for use within this framework. 1334 Using a protocol in a manner for which is was not designed has 1335 numerous problems. The advertised security characteristics of a 1336 protocol may depend on its being used as designed; when used in other 1337 ways, it may not deliver the expected security characteristics. It 1338 is recommended that any proposed model include a discussion of the 1339 applicability statement of the protocols to be used. 1341 12.1. TLS/TCP Transport Mapping Security Model 1343 SNMP supports multiple transports. The preferred transport for SNMP 1344 over IP is UDP [RFC3417]. An experimental transport for SNMP over 1345 TCP is defined in [RFC3430]. 1347 TLS/TCP will create an association between the TMSM of one SNMP 1348 entity and the TMSM of another SNMP entity. The created "tunnel" may 1349 provide encryption and data integrity. Both encryption and data 1350 integrity are optional features in TLS. The TLS TMSP MUST provide 1351 authentication if auth is requested in the securityLevel of the SNMP 1352 message request (RFC3412 4.1.1). The TLS TM-security model MUST 1353 specify that the messages be encrypted if priv is requested in the 1354 securityLevel parameter of the SNMP message request (RFC3412 4.1.1). 1356 The TLS TM-security model MUST support the TLS Handshake Protocol 1357 with mutual authentication. 1359 12.1.1. tmStateReference for TLS 1361 Upon establishment of a TLS session, the TMSP will cache the state 1362 information. A unique tmStateReference will be passed to the 1363 corresponding MPSP. The MPSP will pass the securityStateReference to 1364 the Message Processing Model for memory management. 1366 The tmStateReference cache: 1367 tmStateReference 1368 tmSecurityStateReference 1369 tmTransportDomain = TCP/IPv4 1370 tmTransportAddress = x.x.x.x:y 1371 tmSecurityModel - TLS TMSM 1372 tmSecurityName = "dbharrington" 1373 tmSecurityLevel = "authPriv" 1375 12.1.2. MPSP for TLS TM-Security Model 1377 messageProcessingModel = SNMPv3 1378 securityModel = TLS TMSM 1379 securityName = tmSecurityName 1380 securityLevel = msgSecurityLevel 1382 12.1.3. MIB Module for TLS Security 1384 Each security model should use its own MIB module, rather than 1385 utilizing the USM MIB, to eliminate dependencies on a model that 1386 could be replaced some day. See RFC3411 section 4.1.1. 1388 The TLS MIB module needs to provide the mapping from model-specific 1389 identity to a model independent securityName. 1391 [todo] Module needs to be worked out once things become stable... 1393 12.2. DTLS/UDP Transport Mapping Security Model 1395 DTLS has been proposed as a UDP-based TLS. Transport Layer Security 1396 (TLS) [RFC2246] traditionally requires a connection-oriented 1397 transport and is usually used over TCP. Datagram Transport Layer 1398 Security (DTLS) [I-D.rescorla-dtls] provides security services 1399 equivalent to TLS for connection-less transports such as UDP. 1401 DTLS provides all the security services needed from an SNMP 1402 architectural point of view. Although it is possible to derive a 1403 securityName from the public key certificates (e.g. the subject 1404 field), this approach requires installing certificates on all SNMP 1405 entities, leading to a certificate management problem which does not 1406 integrate well with established AAA systems. [discuss] why does this 1407 not integrate well with existing AAA systems? 1409 Another option is to run an authentication exchange which is 1410 integrated with TLS, such as Secure Remote Password with TLS 1411 [I-D.ietf-tls-srp]. A similar option would be to use Kerberos 1412 authentication with TLS as defined in [RFC2712]. 1414 It is important to stress that the authentication exchange must be 1415 integrated into the TLS mechanism to prevent man-in-the-middle 1416 attacks. While SASL [RFC2222] is often used on top of a TLS 1417 encrypted channel to authenticate users, this choice seems to be 1418 problematic until the mechanism to cryptographically bind SASL into 1419 the TLS mechanism has been defined. 1421 DTLS will create an association between the TMSM of one SNMP entity 1422 and the TMSM of another SNMP entity. The created "tunnel" may 1423 provide encryption and data integrity. Both encryption and data 1424 integrity are optional features in DTLS. The DTLS TM-security model 1425 MUST provide authentication if auth is requested in the securityLevel 1426 of the SNMP message request (RFC3412 4.1.1). The TLS TM-security 1427 model MUST specify that the messages be encrypted if priv is 1428 requested in the securityLevel parameter of the SNMP message request 1429 (RFC3412 4.1.1). 1431 The DTLS TM-security model MUST support the TLS Handshake Protocol 1432 with mutual authentication. 1434 12.2.1. tmStateReference for DTLS 1436 DTLS has been suggested as a possible secure transport. It is not 1437 clear whether DTLS is a reasonable choice for SNMP interactions. It 1438 is mentioned here only as an example. 1440 Upon establishment of a DTLS session, the TMSP will cache the state 1441 information. A unique tmStateReference will be passed to the 1442 corresponding MPSP. The MPSP will pass the securityStateReference to 1443 the Message Processing Model for memory management. 1445 The tmStateReference cache: 1447 tmStateReference 1448 tmSecurityStateReference 1449 tmTransportDomain = UDP/IPv4 1450 tmTransportAddress = x.x.x.x:y 1451 tmSecurityModel - DTLS TMSM 1452 tmSecurityName = "dbharrington" 1453 tmSecurityLevel = "authPriv" 1455 12.3. SASL Transport Mapping Security Model 1457 The Simple Authentication and Security Layer (SASL) [RFC2222] 1458 provides a hook for authentication and security mechanisms to be used 1459 in application protocols. SASL supports a number of authentication 1460 and security mechanisms, among them Kerberos via the GSSAPI mechanism 1461 [RFC4121]. 1463 This sample will use DIGEST-MD5 because it supports authentication, 1464 integrity checking, and confidentiality. 1466 DIGEST-MD5 supports auth, auth with integrity, and auth with 1467 confidentiality. Since SNMPv3 assumes integrity checking is part of 1468 authentication, if msgFlags is set to authNoPriv, the qop-value 1469 should be set to auth-int; if msgFlags is authPriv, then qop-value 1470 should be auth-conf. 1472 Realm is optional, but can be utilized by the securityModel if 1473 desired. SNMP does not use this value, but a TMSM could map the 1474 realm into SNMP processing in various ways. For example, realm and 1475 username could be concatenated to be the securityName value, e.g. 1476 helpdesk::username", or the realm could be used to specify a 1477 groupName to use in the VACM access control. This would be similar 1478 to having the securityName-to-group mapping done by the external AAA 1479 server. 1481 12.3.1. tmStateReference for SASL DIGEST-MD5 1483 The tmStateReference cache: 1484 tmStateReference 1485 tmSecurityStateReference 1486 tmTransportDomain = TCP/IPv4 1487 tmTransportAddress = x.x.x.x:y 1488 tmSecurityModel - SASL TMSM 1489 tmSecurityName = username 1490 tmSecurityLevel = [auth-conf] 1491 tmAuthProtocol = md5-sess 1492 tmPrivProtocol = 3des 1493 tmServicesProvided mutual authentication, 1494 reauthentication, 1495 integrity, 1496 encryption 1497 tmParameters = "realm=helpdesk, serv-type=SNMP 1499 13. The TMSM MIB Module 1501 This memo defines a portion of the Management Information Base (MIB) 1502 for managing the Transport Mapping Security Model Subsystem. 1504 13.1. Structure of the MIB Module 1506 Objects in this MIB module are arranged into subtrees. Each subtree 1507 is organized as a set of related objects. The overall structure and 1508 assignment of objects to their subtrees, and the intended purpose of 1509 each subtree, is shown below. 1511 13.1.1. Textual Conventions 1513 Generic and Common Textual Conventions used in this document can be 1514 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1516 13.1.2. The tmsmStats Subtree 1518 This subtree contains security-model-independent counters which are 1519 applicable to all security models based on the .Transport Mapping 1520 Security Model Subsystem. 1522 This subtree provides information for identifying fault conditions 1523 and performance degradation. 1525 13.1.3. The tmsmsSession Subtree 1527 This subtree contains security-model-independent information about 1528 sessions which are applicable to all security models based on the 1529 Transport Mapping Security Model Subsystem. 1531 This subtree provides information for managing sessions for any 1532 security model based on the Transport Mapping Security Model 1533 Subsystem. 1535 13.1.4. The Notifications Subtree 1537 This subtree contains notifications to alert other entities to events 1538 which could alter the operational behavior of the entity in a network 1539 utilizing the SAMPLE Protocol. 1541 13.2. Relationship to Other MIB Modules 1543 Some management objects defined in other MIB modules are applicable 1544 to an entity implementing this MIB. In particular, it is assumed 1545 that an entity implementing the TMSM-MIB module will also implement 1546 the SNMPv2-MIB [RFC3418]. 1548 This MIB module is expected to be used with the MIB modules defined 1549 for managing specific security models that are based on the TMSM 1550 subsystem. This MIB module is designed to be security-model 1551 independent, and conatins objects useful for managing common aspects 1552 of any TMSM-based security model. Specific security models may 1553 define a MIB module to contain security-model-dependent information. 1555 13.2.1. Relationship to the SNMPv2-MIB 1557 The 'system' subtree in the SNMPv2-MIB [RFC3418] is defined as being 1558 mandatory for all systems, and the objects apply to the entity as a 1559 whole. The 'system' subtree provides identification of the 1560 management entity and certain other system-wide data. The TMSM-MIB 1561 utilizes, but does not dupicate, some of those objects. [todo] do we 1562 actually use any of the objects, since we don't have any elements of 1563 procedure? 1565 13.2.2. MIB Modules Required for IMPORTS 1567 The following MIB module imports items from [RFC2578], [RFC2579], 1568 [RFC2580], [RFC3411], and [RFC3419] 1570 14. Definitions 1572 TMSM-MIB DEFINITIONS ::= BEGIN 1574 IMPORTS 1575 MODULE-IDENTITY, OBJECT-TYPE, 1576 mib-2, Integer32, Unsigned32, Gauge32 1577 FROM SNMPv2-SMI 1578 TestAndIncr 1579 FROM SNMPv2-TC 1580 MODULE-COMPLIANCE, OBJECT-GROUP 1581 FROM SNMPv2-CONF 1582 SnmpSecurityModel, 1583 SnmpAdminString, SnmpSecurityLevel, SnmpEngineID 1584 FROM SNMP-FRAMEWORK-MIB 1585 TransportAddress, TransportAddressType 1586 FROM TRANSPORT-ADDRESS-MIB 1587 ; 1589 tmsmMIB MODULE-IDENTITY 1590 LAST-UPDATED "200602270000Z" 1591 ORGANIZATION "ISMS Working Group" 1592 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1593 Subscribe: isms-request@lists.ietf.org 1595 Chairs: 1596 Juergen Quittek 1597 NEC Europe Ltd. 1598 Network Laboratories 1599 Kurfuersten-Anlage 36 1600 69115 Heidelberg 1601 Germany 1602 +49 6221 90511-15 1603 quittek@netlab.nec.de 1605 Juergen Schoenwaelder 1606 International University Bremen 1607 Campus Ring 1 1608 28725 Bremen 1609 Germany 1610 +49 421 200-3587 1611 j.schoenwaelder@iu-bremen.de 1613 Editor: 1614 David Harrington 1615 Effective Software 1616 50 Harding Rd 1617 Portsmouth, New Hampshire 03801 1618 USA 1619 +1 603-436-8634 1620 ietfdbh@comcast.net 1621 " 1622 DESCRIPTION "The Transport Mapping Security Model 1623 Subsystem MIB 1625 Copyright (C) The Internet Society (2006). This 1626 version of this MIB module is part of RFC XXXX; 1627 see the RFC itself for full legal notices. 1628 -- NOTE to RFC editor: replace XXXX with actual RFC number 1629 -- for this document and remove this note 1630 " 1632 REVISION "200602270000Z" -- 27 February 2006 1633 DESCRIPTION "The initial version, published in RFC XXXX. 1635 -- NOTE to RFC editor: replace XXXX with actual RFC number 1636 -- for this document and remove this note 1637 " 1639 ::= { mib-2 xxxx } 1640 -- RFC Ed.: replace xxxx with IANA-assigned number and 1641 -- remove this note 1643 -- ---------------------------------------------------------- -- 1644 -- subtrees in the TMSM-MIB 1645 -- ---------------------------------------------------------- -- 1647 tmsmNotifications OBJECT IDENTIFIER ::= { tmsmMIB 0 } 1648 tmsmObjects OBJECT IDENTIFIER ::= { tmsmMIB 1 } 1649 tmsmConformance OBJECT IDENTIFIER ::= { tmsmMIB 2 } 1651 -- ------------------------------------------------------------- 1652 -- Objects 1653 -- ------------------------------------------------------------- 1655 -- Statistics for the Transport Model Security Model Subsystem 1657 tmsmStats OBJECT IDENTIFIER ::= { tmsmObjects 1 } 1659 -- [discuss] do we need any tmsm stats? 1660 -- these should be for interoperability, not local debug. 1661 -- we could probably track session establishment failures 1662 -- although this really belongs in an SSH-MIB, not TMSM-MIB 1664 -- The tmsmSession Group 1666 tmsmSession OBJECT IDENTIFIER ::= { tmsmObjects 2 } 1668 tmsmSessionSpinLock OBJECT-TYPE 1669 SYNTAX TestAndIncr 1670 MAX-ACCESS read-write 1671 STATUS current 1672 DESCRIPTION "An advisory lock used to allow several cooperating 1673 TMSM security models to coordinate their 1674 use of facilities to create sessions in the 1675 tmsmSessionTable. 1676 " 1677 ::= { tmsmSession 1 } 1679 tmsmSessionCurrent OBJECT-TYPE 1680 SYNTAX Gauge32 1681 MAX-ACCESS read-only 1682 STATUS current 1683 DESCRIPTION "The current number of established sessions. 1684 " 1685 ::= { tmsmSession 2 } 1687 tmsmSessionMaxSupported OBJECT-TYPE 1688 SYNTAX Unsigned32 1689 MAX-ACCESS read-only 1690 STATUS current 1691 DESCRIPTION "The maximum number of open sessions allowed. 1692 " 1693 ::= { tmsmSession 3 } 1695 tmsmSessionTable OBJECT-TYPE 1696 SYNTAX SEQUENCE OF TmsmSessionEntry 1697 MAX-ACCESS not-accessible 1698 STATUS current 1699 DESCRIPTION "The table of currently available sessions configured 1700 in the SNMP engine's Local Configuration Datastore 1701 (LCD). 1703 Sessions are created as needed, and do not persist 1704 across network management system reboots. 1705 " 1706 ::= { tmsmSession 4 } 1708 tmsmSessionEntry OBJECT-TYPE 1709 SYNTAX TmsmSessionEntry 1710 MAX-ACCESS not-accessible 1711 STATUS current 1712 DESCRIPTION "A session configured in the SNMP engine's Local 1713 Configuration Datastore (LCD) for Transport Mapping 1714 Security Models. 1715 " 1716 INDEX { tmsmSessionID } 1717 ::= { tmsmSessionTable 1 } 1719 TmsmSessionEntry ::= SEQUENCE 1720 { 1721 tmsmSessionID Integer32, 1722 tmsmSessionTransport TransportAddressType, 1723 tmsmSessionAddress TransportAddress, 1724 tmsmSessionSecurityModel SnmpSecurityModel, 1725 tmsmSessionSecurityName SnmpAdminString, 1726 tmsmSessionSecurityLevel SnmpSecurityLevel, 1727 tmsmSessionEngineID SnmpEngineID 1729 } 1731 tmsmSessionID OBJECT-TYPE 1732 SYNTAX Integer32 (1..65535) 1733 MAX-ACCESS not-accessible 1734 STATUS current 1735 DESCRIPTION "A locally-unique identifier for a session. 1736 " 1737 ::= { tmsmSessionEntry 1 } 1739 tmsmSessionTransport OBJECT-TYPE 1740 SYNTAX TransportAddressType 1741 MAX-ACCESS read-only 1742 STATUS current 1743 DESCRIPTION "The transport domain associated with this session. 1744 " 1745 ::= { tmsmSessionEntry 2 } 1747 tmsmSessionAddress OBJECT-TYPE 1748 SYNTAX TransportAddress 1749 MAX-ACCESS read-only 1750 STATUS current 1751 DESCRIPTION "The transport address associated with this session. 1752 " 1753 ::= { tmsmSessionEntry 3 } 1755 tmsmSessionSecurityModel OBJECT-TYPE 1756 SYNTAX SnmpSecurityModel 1757 MAX-ACCESS read-only 1758 STATUS current 1759 DESCRIPTION "The Security Model associated with this session." 1760 ::= { tmsmSessionEntry 4 } 1762 tmsmSessionSecurityName OBJECT-TYPE 1763 SYNTAX SnmpAdminString 1764 MAX-ACCESS read-only 1765 STATUS current 1766 DESCRIPTION "A human readable string representing the principal 1767 in Security Model independent format. 1769 The default transformation of the Secure Shell 1770 Security Model dependent security ID to the 1771 securityName 1772 and vice versa is the identity function so that the 1773 securityName is the same as the SSH user name. 1774 " 1775 ::= { tmsmSessionEntry 5 } 1777 tmsmSessionSecurityLevel OBJECT-TYPE 1778 SYNTAX SnmpSecurityLevel 1779 MAX-ACCESS read-only 1780 STATUS current 1781 DESCRIPTION "The Level of Security at which SNMP messages can be 1782 sent using this session, in particular, one of: 1784 noAuthNoPriv - without authentication and 1785 without privacy, 1786 authNoPriv - with authentication but 1787 without privacy, 1788 authPriv - with authentication and 1789 with privacy. 1790 " 1791 DEFVAL { authPriv } 1792 ::= { tmsmSessionEntry 6 } 1794 tmsmSessionEngineID OBJECT-TYPE 1795 SYNTAX SnmpEngineID 1796 MAX-ACCESS read-only 1797 STATUS current 1798 DESCRIPTION "The administratively-unique identifier for the 1799 remote SNMP engine associated with this session. 1800 " 1801 ::= { tmsmSessionEntry 7 } 1803 -- ------------------------------------------------------------- 1804 -- tmsmMIB - Conformance Information 1805 -- ------------------------------------------------------------- 1807 tmsmGroups OBJECT IDENTIFIER ::= { tmsmConformance 1 } 1809 tmsmCompliances OBJECT IDENTIFIER ::= { tmsmConformance 2 } 1811 -- ------------------------------------------------------------- 1812 -- Units of conformance 1813 -- ------------------------------------------------------------- 1814 tmsmGroup OBJECT-GROUP 1815 OBJECTS { 1816 tmsmSessionCurrent, 1817 tmsmSessionMaxSupported, 1818 tmsmSessionTransport, 1819 tmsmSessionAddress, 1820 tmsmSessionSecurityModel, 1821 tmsmSessionSecurityName, 1822 tmsmSessionSecurityLevel, 1823 tmsmSessionEngineID, 1824 tmsmSessionSpinLock 1826 } 1827 STATUS current 1828 DESCRIPTION "A collection of objects for maintaining session 1829 information of an SNMP engine which implements the 1830 SNMP Secure Shell Security Model. 1831 " 1833 ::= { tmsmGroups 2 } 1835 -- ------------------------------------------------------------- 1836 -- Compliance statements 1837 -- ------------------------------------------------------------- 1839 tmsmCompliance MODULE-COMPLIANCE 1840 STATUS current 1841 DESCRIPTION 1842 "The compliance statement for SNMP engines that support the 1843 TMSM-MIB" 1844 MODULE 1845 MANDATORY-GROUPS { tmsmGroup } 1846 ::= { tmsmCompliances 1 } 1848 END 1850 15. Implementation Considerations 1852 15.1. Applications that Benefit from Sessions 1854 [todo] contributions welcome. 1856 There has been discussion of ways SNMP could be extended to better 1857 support management/monitoring needs when a network is running just 1858 fine. Use of a TCP transport, for example, could enable larger 1859 message sizes and more efficient table retrievals. 1861 Discussing how to improve SNMP once you have less strict message size 1862 constraints is beyond the scope of this document, or that of TMSM- 1863 based security models. Applications utilizing TMSM-based security 1864 models may want to take advantage of the increased message sizes by 1865 sending larger requests and utilizing existing SNMP operations (e.g. 1866 getbulk) effectively. However, doing so might have negative impacts 1867 on existing SNMP management and the networks that contain them. 1869 15.2. Applications that Suffer from Sessions 1871 [todo] contributions welcome. 1873 15.2.1. Troubleshooting 1875 It has been a long-standing requirement that SNMP be able to work 1876 when the network is unstable, to enable network troubleshooting and 1877 repair. The UDP approach has been considered to meet that need well, 1878 with an assumption that getting small messages through, even if out 1879 of order, is better than gettting no messages through. There has 1880 been a long debate about whether UDP actually offers better support 1881 than TCP when the underlying IP or lower layers are unstable. There 1882 has been recent discussion of whether operators actually use SNMP to 1883 troubleshoot and repair unstable networks. 1885 The need to establish a session before using SNMP to troubleshoot a 1886 device may prove problematic in practice. TMSM-based security models 1887 should include discussion of how troubleshooting applications might 1888 be impacted by the use of the specific security model, and recommend 1889 workarounds. 1891 This document RECOMMENDS that all TMSM-based security models include 1892 a fallback approach, triggered by multiple failed attempts to 1893 establish sessions. The default fallback should be to utilize the 1894 IETF-Standard USM security model to send a notification, so an 1895 administrator can attempt to manually correct the problem. 1897 16. Security Considerations 1899 This document describes an architectural approach and multiple 1900 proposed configurations that would permit SNMP to utilize transport 1901 layer security services. Each section containing a proposal should 1902 discuss the security considerations of that approach. [discuss] 1903 expand as needed. 1905 It is considered desirable by some industry segments that SNMP 1906 security models should utilize transport layer security that 1907 addresses perfect forward secrecy at least for encryption keys. 1908 Perfect forward secrecy guarantees that compromise of long term 1909 secret keys does not result in disclosure of past session keys. 1911 There are a number of management objects defined in this MIB module 1912 with a MAX-ACCESS clause of read-write and/or read-create. Such 1913 objects may be considered sensitive or vulnerable in some network 1914 environments. The support for SET operations in a non-secure 1915 environment without proper protection can have a negative effect on 1916 network operations. These are the tables and objects and their 1917 sensitivity/vulnerability: 1918 o [todo] list the tables and objects and state why they are 1919 sensitive. 1921 There are no management objects defined in this MIB module that have 1922 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1923 MIB module is implemented correctly, then there is no risk that an 1924 intruder can alter or create any management objects of this MIB 1925 module via direct SNMP SET operations. 1927 Some of the readable objects in this MIB module (i.e., objects with a 1928 MAX-ACCESS other than not-accessible) may be considered sensitive or 1929 vulnerable in some network environments. It is thus important to 1930 control even GET and/or NOTIFY access to these objects and possibly 1931 to even encrypt the values of these objects when sending them over 1932 the network via SNMP. These are the tables and objects and their 1933 sensitivity/vulnerability: 1934 o [todo] list the tables and objects and state why they are 1935 sensitive. 1937 SNMP versions prior to SNMPv3 did not include adequate security. 1938 Even if the network itself is secure (for example by using IPSec), 1939 even then, there is no control as to who on the secure network is 1940 allowed to access and GET/SET (read/change/create/delete) the objects 1941 in this MIB module. 1943 It is RECOMMENDED that implementers consider the security features as 1944 provided by the SNMPv3 framework (see [RFC3410], section 8), 1945 including full support for the SNMPv3 cryptographic mechanisms (for 1946 authentication and privacy). 1948 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1949 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1950 enable cryptographic security. It is then a customer/operator 1951 responsibility to ensure that the SNMP entity giving access to an 1952 instance of this MIB module is properly configured to give access to 1953 the objects only to those principals (users) that have legitimate 1954 rights to indeed GET or SET (change/create/delete) them. 1956 17. IANA Considerations 1957 The MIB module in this document uses the following IANA-assigned 1958 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1960 Descriptor OBJECT IDENTIFIER value 1961 ---------- ----------------------- 1963 tmsmMIB { mib-2 XXXX } 1965 Editor's Note (to be removed prior to publication): the IANA is 1966 requested to assign a value for "XXXX" under the 'mib-2' subtree 1967 and to record the assignment in the SMI Numbers registry. When 1968 the assignment has been made, the RFC Editor is asked to replace 1969 "XXXX" (here and in the MIB module) with the assigned value and to 1970 remove this note. 1972 [discuss] How do we add a new TransportType? 1974 18. Acknowledgments 1976 The Integrated Security for SNMP WG would like to thank the following 1977 people for their contributions to the process: 1979 The authors of submitted security model proposals: Chris Elliot, Wes 1980 Hardaker, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave 1981 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1983 The members of the Protocol Evaluation Team: Uri Blumenthal, 1984 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1986 WG members who committed to and performed detailed reviews: Jeffrey 1987 Hutzelman 1989 19. References 1991 19.1. Normative References 1993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1994 Requirement Levels", BCP 14, RFC 2119, March 1997. 1996 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1997 (SASL)", RFC 2222, October 1997. 1999 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2000 RFC 2246, January 1999. 2002 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2003 Schoenwaelder, Ed., "Structure of Management Information 2004 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2006 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2007 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2008 STD 58, RFC 2579, April 1999. 2010 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2011 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2012 April 1999. 2014 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2015 "Remote Authentication Dial In User Service (RADIUS)", 2016 RFC 2865, June 2000. 2018 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2019 Architecture for Describing Simple Network Management 2020 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2021 December 2002. 2023 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 2024 "Message Processing and Dispatching for the Simple Network 2025 Management Protocol (SNMP)", STD 62, RFC 3412, 2026 December 2002. 2028 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2029 (USM) for version 3 of the Simple Network Management 2030 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2032 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 2033 Management Protocol (SNMP)", STD 62, RFC 3417, 2034 December 2002. 2036 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2037 Simple Network Management Protocol (SNMP)", STD 62, 2038 RFC 3418, December 2002. 2040 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 2041 Transport Addresses", RFC 3419, December 2002. 2043 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol 2044 Over Transmission Control Protocol Transport Mapping", 2045 RFC 3430, December 2002. 2047 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2048 Protocol Architecture", RFC 4251, January 2006. 2050 [I-D.rescorla-dtls] 2051 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2052 Security", draft-rescorla-dtls-05 (work in progress), 2053 June 2005. 2055 19.2. Informative References 2057 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 2058 Suites to Transport Layer Security (TLS)", RFC 2712, 2059 October 1999. 2061 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2062 "Introduction and Applicability Statements for Internet- 2063 Standard Management Framework", RFC 3410, December 2002. 2065 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2066 Management Protocol (SNMP) Applications", STD 62, 2067 RFC 3413, December 2002. 2069 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 2070 Version 5 Generic Security Service Application Program 2071 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 2072 July 2005. 2074 [I-D.ietf-netconf-ssh] 2075 Wasserman, M. and T. Goddard, "Using the NETCONF 2076 Configuration Protocol over Secure Shell (SSH)", 2077 draft-ietf-netconf-ssh-05 (work in progress), 2078 October 2005. 2080 [I-D.ietf-tls-srp] 2081 Taylor, D., "Using SRP for TLS Authentication", 2082 draft-ietf-tls-srp-10 (work in progress), October 2005. 2084 Appendix A. Questions about msgFlags: 2086 [discuss] many of these questions can be resolved by deciding whether 2087 the TMSP or MPSP provides the service of comparing msgFlags (from 2088 inside the message) to actual capabilities of the transport layer 2089 security (external to the message). It may however be necessary to 2090 provide this service for two slightly different purposes depending on 2091 whether the message is outgoing (and may need to be checked by the 2092 TMSP when a new transport session might be created) or the message is 2093 incoming ( the capabilities of the transport layer session are 2094 already known, but msgFlags has not been unpacked yet at the TMSP, so 2095 the comparison must be done at the MPSP). Of course, we really only 2096 need to compare the authflag and the privflag, i.e. the 2097 securityLevel, so if we pass the securityLevel between the two 2098 stages, then they each have the info they need to do their respective 2099 comparisons. 2101 There have been a large number of questions about msgFlags in the 2102 TMSM approach, mostly concerning the msgFlags value and the actual 2103 security provided, and whether msgFlags can be used to initiate per- 2104 message or per-session security. 2106 A.1. msgFlags versus actual security 2108 Using IPSEC, SSH, or SSL/TLS to provide security services "below" the 2109 SNMP message, the use of securityName and securityLevel will differ 2110 from the USM/VACM approach to SNMP access control. VACM uses the 2111 "securityName" and the "securityLevel" to determine if access is 2112 allowed. With the SNMPv3 message and USM security model, both 2113 securityLevel and securityName are contained in every SNMPv3 message. 2115 Any proposal for a security model using IPSEC, SSH, or SSL/TLS needs 2116 to specify how this info is made available to the SNMPv3 message 2117 processing, and how it is used. 2119 One specific case to consider is the relationship between the 2120 msgFlags of an SNMPv3 message, and the actual services provided by 2121 the lower layer security. For example, if a session is set up with 2122 encryption, is the priv bit always (or never) set in the msgFlags 2123 field, and is the PDU never (or always) encrypted? Do msgFlags have 2124 to match the security services provided by the lower layer, or are 2125 the msgFlags ignored and the values from the lower layer used? 2127 Is the securityLevel looked at before the security model gets to 2128 it.? No. the security model has two parts - the TMSP and the 2129 MPSP. The securityLevel is looked at by the TMSP before it gets 2130 to the MPSP, but both are parts of the same security model. 2131 Would it be legal for the security model to ignore the incoming 2132 flags and change them before passing them back up? If it changed 2133 them, it wouldn't necessarily be ignoring them. The TMSP should 2134 pass both an actual securityLevel applied to the message, and the 2135 msgFlags in the SNMP message to the MPSP for consideration related 2136 to access control.. The msgFlags parameter in the SNMP message is 2137 never changed when processing an incoming message. 2138 Would it be legal for the security model to ignore the outgoing 2139 flags and change them before passing them out? no; because the two 2140 stages are parts of the same security model, either the MPSP 2141 should recognize that a securityLevel cannot be met or exceeded, 2142 and reject the message during the message-build phase, or the TMSP 2143 should determine if it is possible to honor the request. It is 2144 possible to apply an increased securityLevel for an outgoing 2145 request, but the procedure to do so must be spelled out clearly in 2146 the model design. 2147 The security model MUST check the incoming security level flags to 2148 make sure they matched the transport session setup. and if not 2149 drop the message. Yes, mostly. Depending on the model, either 2150 the TMSP or the MPSP MUST verify that the actual processing met or 2151 exceeded the securityLevel requested by the msgFlags and that it 2152 is acceptable to the specific-model processing (or operator 2153 configuration) for this different securityLevel to be applied to 2154 the message. This is also true (especially) for outgoing 2155 messages. 2156 You might legally be able to have a authNoPriv message that is 2157 actually encrypted via the transport (but not the other way around 2158 of course). Yes, a TMSM could define that as the behavior (or 2159 permit an operator to specify that is acceptable behavior) when a 2160 requested securityLevel cannot be provided, but a stronger 2161 securityLevel can be provided. 2163 Appendix B. Parameter Table 2165 Following is a CSV-formatted matrix useful for tracking data flows 2166 into and out of the dispatcher, message, and security subsystems. 2167 Import this into your favorite spreadsheet or other CSV-compatible 2168 application. You wil need to remove lines feeds from the second and 2169 thrid lines, which needed to be wrapped to fit into RFC limits. 2171 B.1. ParameterList.csv 2173 ,Dispatcher,,,,Messaging,,,Security,, 2175 ,sendPDU,returnResponse,processPDU,processResponse 2176 ,prepareOutgoingMessage,prepareResponseMessage,prepareDataElements 2177 ,generateRequest,processIncoming,generateResponse 2179 transportDomain,In,,,,In,,In,,, 2181 transportAddress,In,,,,In,,In,,, 2183 destTransportDomain,,,,,Out,Out,,,, 2185 destTransportAddress,,,,,Out,Out,,,, 2187 messageProcessingModel,In,In,In,In,In,In,Out,In,In,In 2189 securityModel,In,In,In,In,In,In,Out,In,In,In 2191 securityName,In,In,In,In,In,In,Out,In,Out,In 2192 securityLevel,In,In,In,In,In,In,Out,In,In,In 2194 contextEngineID,In,In,In,In,In,In,Out,,, 2196 contextName,In,In,In,In,In,In,Out,,, 2198 expectResponse,In,,,,In,,,,, 2200 PDU,In,In,In,In,In,In,Out,,, 2202 pduVersion,In,In,In,In,In,In,Out,,, 2204 statusInfo,Out,In,,In,,In,Out,Out,Out,Out 2206 errorIndication,Out,Out,,,,,Out,,, 2208 sendPduHandle,Out,,,In,In,,Out,,, 2210 maxSizeResponsePDU,,In,In,,,In,Out,,Out, 2212 stateReference,,In,In,,,In,Out,,, 2214 wholeMessage,,,,,Out,Out,,Out,In,Out 2216 messageLength,,,,,Out,Out,,Out,In,Out 2218 maxMessageSize,,,,,,,,In,In,In 2220 globalData,,,,,,,,In,,In 2222 securityEngineID,,,,,,,,In,Out,In 2224 scopedPDU,,,,,,,,In,Out,In 2226 securityParameters,,,,,,,,Out,,Out 2228 securityStateReference,,,,,,,,,Out,In 2230 pduType,,,,,,,Out,,, 2232 tmStateReference,,,,,,Out,In,,In, 2234 Appendix C. Open Issues 2235 Appendix D. Change Log 2237 NOTE to RFC editor: Please remove this change log before publishing 2238 this document as an RFC. 2240 Changes from revison -00- 2241 changed SSH references from I-Ds to RFCs 2242 removed parameters from tmState Reference for DTLS that revealed 2243 lower layer info. 2244 Added TMSM-MIB module 2245 Added Internet-Standard Management Framework boilerplate 2246 Added Structure of the MIB Module 2247 Added MIB security considerations boilerplate (to be completed) 2248 Added IANA Considerations 2249 Added ASI Parameter table 2250 Added discussion of Sessions 2251 Added Open issues and Change Log 2252 Rearranged sections 2254 Authors' Addresses 2256 David Harrington 2257 Futurewei Technologies 2258 1700 Alma Dr. Suite 100 2259 Plano, TX 75075 2260 USA 2262 Phone: +1 603 436 8634 2263 EMail: dharrington@huawei.com 2265 Juergen Schoenwaelder 2266 International University Bremen 2267 Campus Ring 1 2268 28725 Bremen 2269 Germany 2271 Phone: +49 421 200-3587 2272 EMail: j.schoenwaelder@iu-bremen.de 2274 Full Copyright Statement 2276 Copyright (C) The Internet Society (2006). 2278 This document is subject to the rights, licenses and restrictions 2279 contained in BCP 78, and except as set forth therein, the authors 2280 retain all their rights. 2282 This document and the information contained herein are provided on an 2283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2285 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2286 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2287 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2290 Intellectual Property 2292 The IETF takes no position regarding the validity or scope of any 2293 Intellectual Property Rights or other rights that might be claimed to 2294 pertain to the implementation or use of the technology described in 2295 this document or the extent to which any license under such rights 2296 might or might not be available; nor does it represent that it has 2297 made any independent effort to identify any such rights. Information 2298 on the procedures with respect to rights in RFC documents can be 2299 found in BCP 78 and BCP 79. 2301 Copies of IPR disclosures made to the IETF Secretariat and any 2302 assurances of licenses to be made available, or the result of an 2303 attempt made to obtain a general license or permission for the use of 2304 such proprietary rights by implementers or users of this 2305 specification can be obtained from the IETF on-line IPR repository at 2306 http://www.ietf.org/ipr. 2308 The IETF invites any interested party to bring to its attention any 2309 copyrights, patents or patent applications, or other proprietary 2310 rights that may cover technology that may be required to implement 2311 this standard. Please address the information to the IETF at 2312 ietf-ipr@ietf.org. 2314 Acknowledgement 2316 Funding for the RFC Editor function is currently provided by the 2317 Internet Society.