idnits 2.17.1 draft-ietf-isms-tmsm-02.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 2074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2098. ** 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 390 has weird spacing: '...patcher v ...' == 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 (May 3, 2006) is 6565 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 5 errors (**), 0 flaws (~~), 4 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: November 4, 2006 J. Schoenwaelder 5 International University Bremen 6 May 3, 2006 8 Transport Mapping Security Model (TMSM) Architectural Extension for the 9 Simple Network Management Protocol (SNMP) 10 draft-ietf-isms-tmsm-02.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 November 4, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes a Transport Mapping Security Model (TMSM) 44 extension 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 sessions in the Transport Mapping Security Model 51 extension. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. The Internet-Standard Management Framework . . . . . . . . 4 57 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Requirements of a Transport Mapping Security Model . . . . . . 6 61 2.1. Message Security Requirements . . . . . . . . . . . . . . 6 62 2.1.1. Security Protocol Requirements . . . . . . . . . . . . 7 63 2.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 7 64 2.2.1. Architectural Modularity Requirements . . . . . . . . 7 65 2.2.2. Access Control Requirements . . . . . . . . . . . . . 14 66 2.2.3. Security Parameter Passing Requirements . . . . . . . 16 67 2.3. Session Requirements . . . . . . . . . . . . . . . . . . . 17 68 2.3.1. Session Establishment Requirements . . . . . . . . . . 18 69 2.3.2. Session Maintenance Requirements . . . . . . . . . . . 19 70 2.3.3. Message security versus session security . . . . . . . 19 71 3. Scenario Diagrams for TMSM . . . . . . . . . . . . . . . . . . 21 72 3.1. Command Generator or Notification Originator . . . . . . . 21 73 3.2. Command Responder . . . . . . . . . . . . . . . . . . . . 22 74 4. Abstract Service Interfaces for TMSM . . . . . . . . . . . . . 23 75 4.1. Existing Abstract Service Interfaces . . . . . . . . . . . 24 76 4.2. TMSM Abstract Service Interfaces . . . . . . . . . . . . . 24 77 5. Cached Information and References . . . . . . . . . . . . . . 26 78 5.1. securityStateReference Cached Security Data . . . . . . . 26 79 5.2. tmStateReference Cached Security Data . . . . . . . . . . 27 80 6. Integration with the SNMPv3 Message Format . . . . . . . . . . 28 81 6.1. msgVersion . . . . . . . . . . . . . . . . . . . . . . . . 28 82 6.2. msgGlobalData . . . . . . . . . . . . . . . . . . . . . . 28 83 6.3. securityLevel and msgFlags . . . . . . . . . . . . . . . . 29 84 7. Prepare an Outgoing SNMP Message . . . . . . . . . . . . . . . 29 85 8. Prepare Data Elements from an Incoming SNMP Message . . . . . 30 86 9. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 30 87 10. The TMSM MIB Module . . . . . . . . . . . . . . . . . . . . . 31 88 10.1. Structure of the MIB Module . . . . . . . . . . . . . . . 31 89 10.1.1. The tmsmNotifications Subtree . . . . . . . . . . . . 31 90 10.1.2. The tmsmStats Subtree . . . . . . . . . . . . . . . . 31 91 10.1.3. The tmsmSession Subtree . . . . . . . . . . . . . . . 31 92 10.2. Relationship to Other MIB Modules . . . . . . . . . . . . 31 93 10.2.1. Textual Conventions . . . . . . . . . . . . . . . . . 32 94 10.2.2. MIB Modules Required for IMPORTS . . . . . . . . . . . 32 95 11. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 97 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 98 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 100 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41 101 15.2. Informative References . . . . . . . . . . . . . . . . . . 42 102 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 42 103 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 43 104 Appendix B. Why tmSecurityReference? . . . . . . . . . . . . . . 44 105 B.1. Define an Abstract Service Interface . . . . . . . . . . . 44 106 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 45 107 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 45 108 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 45 109 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 45 110 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 46 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 112 Intellectual Property and Copyright Statements . . . . . . . . . . 47 114 1. Introduction 116 This document describes a Transport Mapping Security Model (TMSM) 117 extension for the Simple Network Management Protocol (SNMP) 118 architecture defined in [RFC3411]. This document identifies and 119 discusses some key aspects that need to be considered for any 120 transport-mapping-based security model for SNMP. 122 1.1. The Internet-Standard Management Framework 124 For a detailed overview of the documents that describe the current 125 Internet-Standard Management Framework, please refer to section 7 of 126 RFC 3410 [RFC3410]. 128 Managed objects are accessed via a virtual information store, termed 129 the Management Information Base or MIB. MIB objects are generally 130 accessed through the Simple Network Management Protocol (SNMP). 131 Objects in the MIB are defined using the mechanisms defined in the 132 Structure of Management Information (SMI). This memo specifies a MIB 133 module that is compliant to the SMIv2, which is described in STD 58, 134 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 135 [RFC2580]. 137 1.2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 Some points requiring further WG research and discussion are 144 identified by [discuss] markers in the text. Some points requiring 145 further editing by the editors are marked [todo] in the text. 147 1.3. Acronyms 149 This section contains a list of acronyms used with the document and 150 references to where in the document the acronym is defined, for easy 151 lookup. 152 o TMSM - a Transport Mapping Security Model 153 o MPSP - s Messaging Processing Security Processor, the portion of a 154 TMSM security model that resides in the Message Processing 155 subsytem of an SNMPv3 engine. See Section 2.2.1 156 o TMSP - the Transport Mapping Security Processor, the portion of a 157 TMSM security model that resides in the Transport Mapping section 158 of the Dispatcher of an SNMPv3 engine. See Section 2.2.1 160 1.4. Motivation 162 There are multiple ways to secure one's home or business, but they 163 largely boil down to a continuum of alternatives. Let's consider 164 three general approaches. In the first approach, an individual could 165 buy a gun, learn to use it, and sit on your front porch waiting for 166 intruders. In the second approach, one could hire an employee with a 167 gun, schedule the employee, position the employee to guard what you 168 want protected, hire a second guard to cover if the first gets sick, 169 and so on. In the third approach, you could hire a security company, 170 tell them what you want protected, and they could hire employees, 171 train them, buy the guns, position the guards, schedule the guards, 172 send a replacement when a guard cannot make it, etc., thus providing 173 the security you want, with no significant effort on your part other 174 than identifying requirements and verifying the quality of the 175 service being provided. 177 The User-based Security Model (USM) as defined in [RFC3414] largely 178 uses the first approach - it provides its own security. It utilizes 179 existing mechanisms (MD5=the gun), but provides all the coordination. 180 USM provides for the authentication of a principal, message 181 encryption, data integrity checking, timeliness checking, etc. 183 USM was designed to be independent of other existing security 184 infrastructures. USM therefore requires a separate user and key 185 management infrastructure. Operators have reported that deploying 186 another user and key management infrastructure in order to use SNMPv3 187 is a deterrent to deploying SNMPv3. It is possible but difficult to 188 define external mechanisms that handle the distribution of keys for 189 use by the USM approach. 191 A solution based on the second approach might use a USM-compliant 192 architecture, but combine the authentication mechanism with an 193 external mechanism, such as RADIUS [RFC2865], to provide the 194 authentication service. It might be possible to utilize an external 195 protocol to encrypt a message, to check timeliness, to check data 196 integrity, etc. It is difficult to cobble together a number of 197 subcontracted services and coordinate them however, because it is 198 difficult to build solid security bindings between the various 199 services, and potential for gaps in the security is significant. 201 A solution based on the third approach might utilize one or more 202 lower-layer security mechanisms to provide the message-oriented 203 security services required. These would include authentication of 204 the sender, encryption, timeliness checking, and data integrity 205 checking. There are a number of IETF standards available or in 206 development to address these problems through security layers at the 207 transport layer or application layer, among them TLS [RFC4366], SASL 209 [RFC2222], and SSH [RFC4251]. 211 From an operational perspective, it is highly desirable to use 212 security mechanisms that can unify the administrative security 213 management for SNMPv3, command line interfaces (CLIs) and other 214 management interfaces. The use of security services provided by 215 lower layers is the approach commonly used for the CLI, and is also 216 the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. 218 This document proposes a Transport Mapping Security Model (TMSM) 219 extension to the RFC3411 architecture, that allows security to be 220 provided by an external protocol connected to the SNMP engine through 221 an SNMP transport-mapping [RFC3417]. Such a TMSM would then enable 222 the use of existing security mechanisms such as (TLS) [RFC4366] or 223 SSH [RFC4251] within the RFC3411 architecture. 225 There are a number of Internet security protocols and mechanisms that 226 are in wide spread use. Many of them try to provide a generic 227 infrastructure to be used by many different application layer 228 protocols. The motivation behind TMSM is to leverage these protocols 229 where it seems useful. 231 There are a number of challenges to be addressed to map the security 232 provided by a secure transport into the SNMP architecture so that 233 SNMP continues to work without any surprises. These challenges are 234 discussed in detail in this document. For some key issues, design 235 choices are discussed that may be made to provide a workable solution 236 that meets operational requirements and fits into the SNMP 237 architecture defined in [RFC3411]. 239 2. Requirements of a Transport Mapping Security Model 241 2.1. Message Security Requirements 243 Transport mapping security protocols SHOULD ideally provide the 244 protection against the following message-oriented threats [RFC3411]: 246 1. modification of information 247 2. masquerade 248 3. message stream modification 249 4. disclosure 251 According to [RFC3411], it is not required to protect against denial 252 of service or traffic analysis. 254 2.1.1. Security Protocol Requirements 256 There are a number of standard protocols that could be proposed as 257 possible solutions within the TMSM framework. Some factors should be 258 considered when selecting a protocol for use within this framework. 260 Using a protocol in a manner for which it was not designed has 261 numerous problems. The advertised security characteristics of a 262 protocol may depend on its being used as designed; when used in other 263 ways, it may not deliver the expected security characteristics. It 264 is recommended that any proposed model include a discussion of the 265 applicability statement of the protocols to be used. 267 A protocol used for the TMSM framework should ideally require no 268 modifications to the protocol. Modifying the protocol may change its 269 security characteristics in ways that would impact other existing 270 usages. If a change is necessary, the change should be an extension 271 that has no impact on the existing usages. It is recommended that 272 any proposed model include a discussion of potential impact on other 273 usages of the protocol. 275 It has been a long-standing requirement that SNMP be able to work 276 when the network is unstable, to enable network troubleshooting and 277 repair. The UDP approach has been considered to meet that need well, 278 with an assumption that getting small messages through, even if out 279 of order, is better than getting no messages through. There has been 280 a long debate about whether UDP actually offers better support than 281 TCP when the underlying IP or lower layers are unstable. There has 282 been recent discussion of whether operators actually use SNMP to 283 troubleshoot and repair unstable networks. 285 There has been discussion of ways SNMP could be extended to better 286 support management/monitoring needs when a network is running just 287 fine. Use of a TCP transport, for example, could enable larger 288 message sizes and more efficient table retrievals. 290 TMSM models MUST be able to coexist with other protocol models, and 291 may be designed to utilize either TCP or UDP, depending on the 292 transport. 294 2.2. SNMP Requirements 296 2.2.1. Architectural Modularity Requirements 298 SNMP version 3 (SNMPv3) is based on a modular architecture (described 299 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 300 standards over time, and to minimize side effects between subsystems 301 when changes are made. The architecture includes a Security 302 Subsystem which is responsible for realizing security services. 304 In SNMPv2, there were many problems of side effects between 305 subsystems caused by the manipulation of MIB objects, especially 306 those related to authentication and authorization, because many of 307 the parameters were stored in shared MIB objects, and different 308 models and protocols could assign different values to the objects. 309 Contributors assumed slightly different shades of meaning depending 310 on the models and protocols being used. As the shared MIB module 311 design was modified to accommodate a specific model, other models 312 which used the same MIB objects were broken. 314 Abstract Service Interfaces (ASIs) were developed to pass model- 315 independent parameters. The models were required to translate from 316 their model-dependent formats into a model-independent format, 317 defined using model-independent semantics, which would not impact 318 other models. 320 Parameters have been provided in the ASIs to pass model-independent 321 information about the authentication that has been provided. These 322 parameters include a model-independent identifier of the security 323 "principal", the security model used to perform the authentication, 324 and which SNMP-specific security features were applied to the message 325 (authentication and/or privacy). 327 Parameters have been provided in the ASIs to pass model-independent 328 transport address information. These parameters utilize the 329 TransportType and TransportAddress 331 The design of a transport mapping security model must abide the goals 332 of the RFC3411 architecture defined in [RFC3411]. To that end, this 333 transport mapping security model proposal uses a modular design that 334 can be advanced through the standards process independently of other 335 proposals, and independent of other modular components as much as 336 possible. 338 IETF standards typically require one mandatory to implement solution, 339 with the capability of adding new security mechanisms in the future. 340 Any transport mapping security model should define one minimum- 341 compliance mechanism, preferably one which is already widely deployed 342 within the transport layer security protocol used. 344 The TMSM architectural extension permits additional transport 345 security protocols to be "plugged into" the RFC3411 architecture, 346 supported by corresponding transport-security-aware transport mapping 347 models. 349 The RFC3411 architecture, and the USM approach, assume that a 350 security model is called by a message-processing model and will 351 perform multiple security functions. The TMSM approach performs 352 similar functions but performs them in different places within the 353 architecture, so we need to distinguish the two locations for 354 security processing. 356 Transport mapping security is by its very nature a security layer 357 which is plugged into the RFC3411 architecture between the transport 358 layer and the message dispatcher. Conceptually, transport mapping 359 security processing will be called from within the Transport Mapping 360 functionality of an SNMP engine dispatcher to perform the translation 361 of transport security parameters to/from security-model-independent 362 parameters. This transport mapping security processor will be 363 referred to in this document as TMSP. 365 Additional functionality may be performed as part of the message 366 processing function, i.e., in the security subsystem of the RFC3411 367 architecture. This document will refer to message processor's 368 security processor as the MPSP. 370 Thus a TMSM is composed of both a TMSP and an MPSP. 372 +------------------------------+ 373 | Network | 374 +------------------------------+ 375 ^ ^ ^ 376 | | | 377 v v v 378 +-----+ +-----+ +-------+ 379 | UDP | | TCP | . . . | other | 380 +-----+ +-----+ +-------+ 381 ^ ^ ^ 382 | | | 383 v v v 384 +-----+ +-----+ +-------+ 385 | SSH | | TLS | . . . | other | 386 +-----+ +-----+ +-------+ (traditional SNMP agent) 387 +-------------------------------------------------------------------+ 388 | ^ | 389 | | | 390 | Dispatcher v | 391 | +-------------------+ | 392 | | Transport | +--------------+ | 393 | | Mapping |<---> | TMSM | | 394 | | (e.g., RFC 3417) | | TMSP | | 395 | | | +--------------+ | 396 | | | | 397 | | | +---------------------+ +----------------+ | 398 | | | | Message Processing | | Security | | 399 | | | | Subsystem | | Subsystem | | 400 | | | | +------------+ | | | | 401 | | | | +->| v1MP * |<--->| +------------+ | | 402 | | | | | +------------+ | | | Other | | | 403 | | | | | +------------+ | | | Security | | | 404 | | | | +->| v2cMP * |<--->| | Model | | | 405 | | Message | | | +------------+ | | +------------+ | | 406 | | Dispatcher <--------->| +------------+ | | +------------+ | | 407 | | | | +->| v3MP * |<--->| | TMSM | | | 408 | | | | | +------------+ | | | MPSP | | | 409 | | PDU Dispatcher | | | +------------+ | | | | | | 410 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 411 | ^ | +------------+ | | | | 412 | | +---------------------+ +----------------+ | 413 | v | 414 | +-------+-------------------------+---------------+ | 415 | ^ ^ ^ | 416 | | | | | 417 | v v v | 418 | +-------------+ +---------+ +--------------+ +-------------+ | 419 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 420 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 421 | | application | | | | applications | | application | | 422 | +-------------+ +---------+ +--------------+ +-------------+ | 423 | ^ ^ | 424 | | | | 425 | v v | 426 | +----------------------------------------------+ | 427 | | MIB instrumentation | SNMP entity | 428 +-------------------------------------------------------------------+ 430 2.2.1.1. USM and the RFC3411 Architecture 432 The following diagrams illustrate the difference in the security 433 processing done by the USM model and the security processing done by 434 a TMSM model. 436 The USM security model is encapsulated by the messaging model, 437 because the messaging model needs to perform the following steps (for 438 incoming messages) 439 1) decode the ASN.1 (messaging model) 440 2) determine the SNMP security model and parameters (messaging model) 441 3) decrypt the encrypted portions of the message (security model) 442 4) translate parameters to model-independent parameters (security 443 model) 444 5) determine which application should get the decrypted portions 445 (messaging model), and 446 6) pass on the decrypted portions with model-independent parameters. 448 The USM approach uses SNMP-specific message security and parameters. 450 | -----------------------------------------------| 451 | transport layer | 452 | -----------------------------------------------| 453 ^ 454 | 455 v 456 -------------------------------------------------- 457 | -----------------------------------------------| 458 | | transport mapping | 459 | -----------------------------------------------| 460 | ^ 461 | | 462 | v 463 | --------------------------------------------- | 464 | --------------------- ------------------ | 465 | SNMP messaging <--> | decryption + | | 466 | | translation | | 467 | --------------------- ------------------ | 468 | ^ 469 | | 470 | v 471 | --------------------- ------------------ | 472 | | SNMP applications | <--> | access control | | 473 | --------------------- ------------------ | 475 | --------------------------------------------- | 477 2.2.1.2. TMSM and the RFC3411 Architecture 479 In the TMSM approach, the order of the steps differ and may be 480 handled by different subsystems: 481 1) decrypt the encrypted portions of the message (transport layer) 482 2) determine the SNMP security model and parameters (transport 483 mapping) 484 3*) translate parameters to model-independent parameters (transport 485 mapping) 486 4) decode the ASN.1 (messaging model) 487 5) determine which application should get the decrypted portions 488 (messaging model) 489 6*) translate parameters to model-independent parameters (security 490 model) 491 7) pass on the decrypted portions with model-independent security 492 parameters 494 This is largely based on having non-SNMP-specific message security 495 and parameters. The transport mapping model might provide the 496 translation from e.g., an SSH user name to the securityName in step 497 3, OR the SSH user might be passed to the messaging model to pass to 498 a TMSM security model to do the translation in step 6, if the WG 499 decides all translations should use the same translation table (e.g., 500 the USM MIB). 502 | -----------------------------------------------| 503 | ------------------ | 504 | transport layer <--> | decryption | | 505 | ------------------ | 506 | -----------------------------------------------| 507 ^ 508 | 509 v 510 -------------------------------------------------- 511 | -----------------------------------------------| 512 | ------------------ | 513 | transport mapping <--> | translation* | | 514 | ------------------ | 515 | -----------------------------------------------| 516 | ^ 517 | | 518 | v 519 | --------------------------------------------- | 520 | ------------------ | 521 | SNMP messaging <--> | translation* | | 522 | ------------------ | 523 | --------------------- ------------------ | 524 | ^ 525 | | 526 | v 527 | --------------------- ------------------ | 528 | | SNMP applications | <--> | access control | | 529 | --------------------- ------------------ | 531 | --------------------------------------------- | 533 2.2.1.3. Passing Information between Engines 535 A TMSM model will establish an encrypted tunnel between the transport 536 mappings of two SNMP engines. One transport mapping security model 537 instance encrypts all messages, and the other transport mapping 538 security model instance decrypts the messages. 540 After the transport layer tunnel is established, then SNMP messages 541 can conceptually be sent through the tunnel from one SNMP message 542 dispatcher to another SNMP message dispatcher. Once the tunnel is 543 established, multiple SNMP messages may be able to be passed through 544 the same tunnel. 546 2.2.2. Access Control Requirements 548 2.2.2.1. securityName Binding 550 For SNMP access control to function properly, the security mechanism 551 must establish a securityModel identifier, a securityLevel, and a 552 securityName, which is the security model independent identifier for 553 a principal. The SNMPv3 message processing architecture subsystem 554 relies on a security model, such as USM, to play a role in security 555 that goes beyond protecting the message - it provides a mapping 556 between the USM-specific principal to a security-model independent 557 securityName which can be used for subsequent processing, such as for 558 access control. 560 The TMSM is a two-stage security model, with a transport mapping 561 security process (TMSP) and a message processing security process 562 (MPSP). Depending on the design of the specific TMSM model, i.e., 563 which transport layer protocol is used, different features might be 564 provided by the TMSP or by the MPSP. For example, the translation 565 from a mechanism-specific authenticated identity to a securityName 566 might be done by the TMSP or by the MPSP. 568 The securityName MUST be bound to the mechanism-specific 569 authenticated identity, and this mapping MUST be done before the MPSP 570 portion of the model passes securityName to the message processing 571 model via the processIncoming() ASI. 573 The SNMP architecture distinguishes between messages with no 574 authentication and no privacy (noAuthNoPriv), authentication without 575 privacy (authNoPriv) and authentication with privacy (authPriv). 576 Hence, the authentication of a transport layer identity plays an 577 important role and must be considered by any TMSM, and user 578 authentication must be available via the transport layer security 579 protocol. 581 If the type of authentication provided by the transport layer (e.g. 582 TLS) is considered adequate to secure and/or encrypt the message, but 583 inadequate to provide the desired granularity of access control (e.g. 584 user-based), then a second authentication (e.g., one provided by a 585 RADIUS server) may be used to provide the authentication identity 586 which is bound to the securityName. This approach would require a 587 good analysis of the potential for man-in-the-middle attacks or 588 masquerade possibilities. 590 2.2.2.2. Separation of Authentication and Authorization 592 A TMSM security model should take care to not violate the separation 593 of authentication and authorization in the RFC3411 architecture. The 594 isAccessAllowed() primitive is used for passing security-model 595 independent parameters between the subsystems of the architecture. 597 Mapping of (securityModel, securityName) to an access control policy 598 should be handled within the access control subsystem, not the 599 security subsystem, to be consistent with the modularity of the 600 RFC3411 architecture. This separation was a deliberate decision of 601 the SNMPv3 WG, to allow support for authentication protocols which 602 did not provide authorization capabilities, and to support 603 authorization schemes, such as VACM, that do not perform their own 604 authentication. 606 An authorization model MAY require authentication by certain 607 securityModels and a minimum securityLevel to allow access to the 608 data. 610 TMSM is an enhancement for the SNMPv3 privacy and authentication 611 provisions, but it is not a significant improvement for the 612 authorization needs of SNMPv3. TMSM provides all the model- 613 independent parameters for the isAccessAllowed() primitive [RFC3411]. 615 TMSM does not specify how the securityModel and securityName could be 616 dynamically mapped to a VACM-style groupName. The mapping of 617 (securityModel, securityName) to a groupName is a VACM-specific 618 mechanism for naming an access control policy, and for tying the 619 named policy to the addressing capabilities of the data modeling 620 language (e.g. SMIv2 [RFC2578]), the operations supported, and other 621 factors. Providing a binding outside the Access Control subsystem 622 might create dependencies that could make it harder to develop 623 alternate models of access control, such as one built on UNIX groups 624 or Windows domains. The preferred approach is to pass the model- 625 independent security parameters via the isAccessAllowed() ASI, and 626 perform the mapping within the access control model. 628 To provide support for protocols which simultaneously send 629 information for authentication and authorization, such as RADIUS 630 [RFC2865], model-specific authorization information MAY be cached or 631 otherwise made available to the access control subsystem, e.g., via a 632 MIB table similar to the vacmSecurityToGroupTable, so the access 633 control subsystem can create an appropriate binding between the 634 model-independent securityModel and securityName and a model-specific 635 access control policy. This may be highly undesirable, however, if 636 it creates a dependency between a security model and an access 637 control model, just as it is undesirable that the TMSM approach 638 creates a dependency between a TMSP and an MPSP. 640 2.2.3. Security Parameter Passing Requirements 642 RFC3411 section 4 describes primitives to describe the abstract data 643 flows between the various subsystems, models and applications within 644 the architecture. Abstract Service Interfaces describe the flow of 645 data between subsystems within an engine. The ASIs generally pass 646 model-independent information. 648 Within an engine using a TMSM-based security model, outgoing SNMP 649 messages are passed unencrypted from the message dispatcher to the 650 transport mapping, and incoming messages are passed unencrypted from 651 the transport mapping to the message dispatcher. 653 The security parameters include a model-independent identifier of the 654 security "principal", the security model used to perform the 655 authentication, and which SNMP-specific security services were 656 (should be) applied to the message (authentication and/or privacy). 658 In the RFC3411 architecture, which reflects the USM security model 659 design, the messaging model must unpack SNMP-specific security 660 parameters from an incoming message before calling a specific 661 security model to authenticate and decrypt an incoming message, 662 perform integrity checking, and translate model-specific security 663 parameters into model-independent parameters. 665 In the TMSM approach, the security-model specific parameters are not 666 carried in the SNMP message. The parameters are provided by SNMP 667 applications for outgoing messages, and the parameters for incoming 668 messages are extracted from the transport layer by the security- 669 model-specific transport mapping before the message is passed to the 670 message processing subsystem. 672 For outgoing messages, it is necessary to have an MPSP because it is 673 the MPSP that actually creates the message from its component parts. 674 Whether there are any security services provided by the MPSP for an 675 outgoing message is model-dependent. 677 For incoming messages, there might be security functionality that can 678 only be handled after the message version is known. The message 679 version is determined by the Message Processing model and passed to 680 the MPSP via the processIncoming() ASI. 682 The RFC3411 architecture has no ASI parameters for passing security 683 information between the transport mapping and the dispatcher, and 684 between the dispatcher and the message processing model. If there is 685 a need to have an MPSP called from the message processing model to, 686 for example, verify that msgFlags and the transport security are 687 consistent, then it will be necessary to pass the model-dependent 688 security parameters from the TMSP through to the MPSP. 690 This document describes a cache, into which the TMSP puts information 691 about the security applied to an incoming message, and an MPSP 692 extracts that information from the cache. Given that there may be 693 multiple TM-security caches, a tmStateReference is passed as an extra 694 parameter in the ASIs between the transport mapping and the messaging 695 security model.so the MPSP knows which cache of information to 696 consult. 698 This approach does create dependencies between a model-specific TMSP 699 and a corresponding specific MPSP. This approach of passing a model- 700 independent reference is consistent with the securityStateReference 701 cache already being passed around in the RFC3411 ASIs. 703 2.3. Session Requirements 705 Throughout this document, the term session is used. Some underlying 706 secure transports will have a notion of session. Some underlying 707 secure transports might enable the use of channels or other session- 708 like thing. In this document the term session refers to an 709 association between two SNMP engines that permits the secure 710 transmission of one or more SNMP messages within the lifetime of the 711 session. How the session is actually established, opened, closed, or 712 maintained is specific to a particular security model. 714 Sessions are not part of the SNMP architecture described in 715 [RFC3411], but are considered desirable because the cost of 716 authentication can be amortized over potentially many transactions. 718 It is important to note that the architecture described in [RFC3411] 719 does not include a session selector in the Abstract Service 720 Interfaces, and neither is that done for this architectural 721 extension, so an SNMP application cannot select the session except by 722 passing a unique combination of securityName, securityModel, and 723 securityLevel. 725 All TMSM-based security models should discuss the impact of sessions 726 on SNMP usage, including how to establish/open a TMSM session (i.e., 727 how it maps to the concepts of session-like things of the underlying 728 protocol), how to behave when a TMSM session cannot be established, 729 how to close a TMSM session (and the underlying protocol equivalent) 730 properly, how to behave when a TMSM session is closed improperly, the 731 session security properties, session establishment overhead, and 732 session maintenance overhead. 734 To reduce redundancy, this document will discuss aspects that are 735 expected to be common to all TMSM-based security model sessions. 737 2.3.1. Session Establishment Requirements 739 SNMP applications must provide the transport address, securityName, 740 securityModel, and securityLevel to be used for a session. 742 SNMP Applications typically have no knowledge of whether the session 743 that will be used to carry commands was initially established as a 744 notification session, or a request-response session, and SHOULD NOT 745 make any assumptions based on knowing the direction of the session. 746 If an administrator or security model designer wants to differentiate 747 a session established for different purposes, such as a notification 748 session versus a request-response session, the application can use 749 different securityNames or transport addresses (e.g., port 161 vs 750 port 162) for different purposes. 752 An SNMP engine containing an application that initiates 753 communication, e.g., a Command Generator or Notification Originator, 754 MUST be able to attempt to establish a session for delivery if a 755 session does not yet exist. If a session cannot be established then 756 the message is discarded. 758 Sessions are usually established by the transport mapping security 759 processor when no appropriate session is found for an outgoing 760 message, but sessions may be established in advance to support 761 features such as notifications and call-home. How sessions are 762 established in advance is beyond the scope of this document. 764 Sessions are initiated by notification originators when there is no 765 currently established connection that can be used to send the 766 notification. For a client-server security protocol, this may 767 require provisioning authentication credentials on the agent, either 768 statically or dynamically, so the client/agent can successfully 769 authenticate to a notification receiver. 771 A TMSM-based security model must be able to determine whether a 772 session does or does not exist, and must be able to determine which 773 session has the appropriate security characteristics (transport 774 address, securityName, securityModel, and securityLevel) for an 775 outgoing message. 777 A TMSM security model implementation MAY reuse an already established 778 session with the appropriate transport address, securityName, 779 securityModel, and securityLevel characteristics for delivery of a 780 message originated by a different type of application than originally 781 caused the session to be created. For example, an implementation 782 that has an existing session originally established to receive a 783 request may use that session to send an outgoing notification, and 784 may use a session that was originally established to send a 785 notification to send a request. Responses are expected to be 786 returned using the same session that carried the corresponding 787 request message. Reuse is not required for conformance. 789 If a session can be reused for a different type of message, but a 790 receiver is not prepared to accept different message types over the 791 same session, then the message MAY be dropped by the manager. 793 2.3.2. Session Maintenance Requirements 795 A TMSM-based security model can tear down sessions as needed. It may 796 be necessary for some implementations to tear down sessions as the 797 result of resource constraints, for example. 799 The decision to tear down a session is implementation-dependent. 800 While it is possible for an implementation to automatically tear down 801 each session once an operation has completed, this is not recommended 802 for anticipated performance reasons. How an implementation 803 determines that an operation has completed, including all potential 804 error paths, is implementation-dependent. 806 Implementations should be careful to not tear down a session between 807 the time a request is received and the time the response is sent. 808 The elements of procedure for TMSM-based security models should be 809 sure to describe the expected behavior when no session exists for a 810 response. 812 The elements of procedure may discuss when cached information can be 813 discarded, and the timing of cache cleanup may have security 814 implications, but cache memory management is an implementation issue. 816 If a security model defines MIB module objects to maintain session 817 state information, then the security model MUST describe what happens 818 to the objects when a related session is torn down, since this will 819 impact interoperability of the MIB module. 821 2.3.3. Message security versus session security 823 A TMSM session is associated with state information that is 824 maintained for its lifetime. This state information allows for the 825 application of various security services to TMSM-based security 826 models. Cryptographic keys established at the beginning of the 827 session SHOULD be used to provide authentication, integrity checking, 828 and encryption services for data that is communicated during the 829 session. The cryptographic protocols used to establish keys for a 830 TMSM-based security model session SHOULD ensure that fresh new 831 session keys are generated for each session. If each session uses 832 new session keys, then messages cannot be replayed from one session 833 to another. In addition sequence information MAY be maintained in 834 the session which can be used to prevent the replay and reordering of 835 messages within a session. 837 A TMSM session will typically have a single transport address, 838 securityName and securityLevel associated with it. If an exchange 839 between communicating engines would require a different securityLevel 840 or would be on behalf of a different securityName, then another 841 session would be needed. An immediate consequence of this is that 842 implementations should be able to maintain some reasonable number of 843 concurrent sessions. 845 For TMSM models, securityName is typically specified during session 846 setup, and associated with the session identifier. 848 SNMPv3 was designed to support multiple levels of security, 849 selectable on a per-message basis by an SNMP application, because 850 there is not much value in using encryption for a Commander Generator 851 to poll for non-sensitive performance data on thousands of interfaces 852 every ten minutes; the encryption adds significant overhead to 853 processing of the messages. 855 Some TMSM-based security models MAY support only specific 856 authentication and encryption services, such as requiring all 857 messages to be carried using both authentication and encryption, 858 regardless of the security level requested by an SNMP application. 860 Some security models may use an underlying transport that provides a 861 per-message requested level of authentication and encryption 862 services. For example, if a session is created as 'authPriv', then 863 keys for encryption could still be negotiated once at the beginning 864 of the session. But if a message is presented to the session with a 865 security level of authNoPriv, then that message could simply be 866 authenticated and not encrypted within the same transport session. 867 Whether this is possible depends on the security model and the secure 868 transport used. 870 If the underlying transport layer security was configurable on a per- 871 message basis, a TMSM-based security model could have a security- 872 model-specific MIB module with configurable maxSecurityLevel and a 873 minSecurityLevel objects to identify the range of possible levels. A 874 session's maxSecurityLevel would identify the maximum security it 875 could provide, and a session created with a minSecurityLevel of 876 authPriv would reject an attempt to send an authNoPriv message. The 877 elements of procedure of the security model would need to describe 878 the procedures to enable this determination. 880 For security models that do not support variable security services in 881 one session, multiple sessions could be established with different 882 security levels, and for every packet the SNMP engine could select 883 the appropriate session based on the requested securityLevel. Some 884 SNMP entities are resource-constrained. Adding sessions increases 885 the need for resources, but so does encrypting unnecessarily. 886 Designers of security models should consider the trade offs for 887 resource-constrained devices. 889 3. Scenario Diagrams for TMSM 891 RFC3411 section 4.6 provides scenario diagrams to illustrate how an 892 outgoing message is created, and how an incoming message is 893 processed. Both diagrams are incomplete, however. In section 4.6.1, 894 the diagram doesn't show the ASI for sending an SNMP request to the 895 network or receiving an SNMP response message from the network. In 896 section 4.6.2, the diagram doesn't illustrate the interfaces required 897 to receive an SNMP message from the network, or to send an SNMP 898 message to the network. 900 3.1. Command Generator or Notification Originator 902 This diagram from RFC3411 4.6.1 shows how a Command Generator or 903 Notification Originator application [RFC3413] requests that a PDU be 904 sent, and how the response is returned (asynchronously) to that 905 application. 907 Command Dispatcher Message Security 908 Generator | Processing Model 909 | | Model | 910 | sendPdu | | | 911 |------------------->| | | 912 | | prepareOutgoingMessage | | 913 : |----------------------->| | 914 : | | generateRequestMsg | 915 : | |-------------------->| 916 : | | | 917 : | |<--------------------| 918 : | | | 919 : |<-----------------------| | 920 : | | | 921 : |------------------+ | | 922 : | Send SNMP | | | 923 : | Request Message | | | 924 : | to Network | | | 925 : | v | | 926 : : : : : 927 : : : : : 928 : : : : : 929 : | | | | 930 : | Receive SNMP | | | 931 : | Response Message | | | 932 : | from Network | | | 933 : |<-----------------+ | | 934 : | | | 935 : | prepareDataElements | | 936 : |----------------------->| | 937 : | | processIncomingMsg | 938 : | |-------------------->| 939 : | | | 940 : | |<--------------------| 941 : | | | 942 : |<-----------------------| | 943 | processResponsePdu | | | 944 |<-------------------| | | 945 | | | | 947 3.2. Command Responder 949 This diagram shows how a Command Responder or Notification Receiver 950 application registers for handling a pduType, how a PDU is dispatched 951 to the application after an SNMP message is received, and how the 952 Response is (asynchronously) send back to the network. 954 Command Dispatcher Message Security 955 Responder | Processing Model 956 | | Model | 957 | | | | 958 | registerContextEngineID | | | 959 |------------------------>| | | 960 |<------------------------| | | | 961 | | Receive SNMP | | | 962 : | Message | | | 963 : | from Network | | | 964 : |<-------------+ | | 965 : | | | 966 : |prepareDataElements | | 967 : |------------------->| | 968 : | | processIncomingMsg | 969 : | |------------------->| 970 : | | | 971 : | |<-------------------| 972 : | | | 973 : |<-------------------| | 974 | processPdu | | | 975 |<------------------------| | | 976 | | | | 977 : : : : 978 : : : : 979 | returnResponsePdu | | | 980 |------------------------>| | | 981 : | prepareResponseMsg | | 982 : |------------------->| | 983 : | |generateResponseMsg | 984 : | |------------------->| 985 : | | | 986 : | |<-------------------| 987 : | | | 988 : |<-------------------| | 989 : | | | 990 : |--------------+ | | 991 : | Send SNMP | | | 992 : | Message | | | 993 : | to Network | | | 994 : | v | | 996 4. Abstract Service Interfaces for TMSM 997 4.1. Existing Abstract Service Interfaces 999 The OUT parameters of the prepareOutgoingMessage() ASI are used to 1000 pass information from the message processing model to the dispatcher 1001 and on to the transport mapping: 1003 statusInformation = -- success or errorIndication 1004 prepareOutgoingMessage( 1005 IN transportDomain -- transport domain to be used 1006 IN transportAddress -- transport address to be used 1007 IN messageProcessingModel -- typically, SNMP version 1008 IN securityModel -- Security Model to use 1009 IN securityName -- on behalf of this principal 1010 IN securityLevel -- Level of Security requested 1011 IN contextEngineID -- data from/at this entity 1012 IN contextName -- data from/in this context 1013 IN pduVersion -- the version of the PDU 1014 IN PDU -- SNMP Protocol Data Unit 1015 IN expectResponse -- TRUE or FALSE 1016 IN sendPduHandle -- the handle for matching 1017 incoming responses 1018 OUT destTransportDomain -- destination transport domain 1019 OUT destTransportAddress -- destination transport address 1020 OUT outgoingMessage -- the message to send 1021 OUT outgoingMessageLength -- its length 1022 ) 1024 4.2. TMSM Abstract Service Interfaces 1026 A set of abstract service interfaces have been defined within this 1027 document to describe the conceptual data flows between the Transport 1028 Mapping Security Models and adjacent components in the system. 1030 The sendMessage ASI is used to pass a message from the Dispatcher to 1031 the transport mapping for sending. 1033 statusInformation = 1034 sendMessage( 1035 IN destTransportDomain -- transport domain to be used 1036 IN destTransportAddress -- transport address to be used 1037 IN outgoingMessage -- the message to send 1038 IN outgoingMessageLength -- its length 1039 IN tmStateReference 1040 OUT sessionID 1041 ) 1043 The recvMessage ASI is used to pass a message from the transport 1044 mapping to the Dispatcher. 1046 statusInformation = 1047 recvMessage( 1048 IN destTransportDomain -- transport domain to be used 1049 IN destTransportAddress -- transport address to be used 1050 IN incomingMessage -- the message received 1051 IN incomingMessageLength -- its length 1052 OUT tmStateReference 1053 OUT sessionID 1054 ) 1056 The Transport Mapping Security Model provides the following 1057 primitives to pass data back and forth between the TMSM and specific 1058 TMSM-based security models, which provide the interface to the 1059 underlying secure transport service. Each TMSM-based security model 1060 should define the security-model-specific elements of procedure for 1061 the openSession(), closeSession(), txMessage(), and rxMessage() 1062 interfaces. 1064 statusInformation = 1065 txMessage( 1066 IN destTransportDomain -- transport domain to be used 1067 IN destTransportAddress -- transport address to be used 1068 IN outgoingMessage -- the message to send 1069 IN outgoingMessageLength -- its length 1070 IN tmStateReference 1071 OUT sessionID 1072 ) 1074 statusInformation = 1075 rxMessage( 1076 IN destTransportDomain -- transport domain to be used 1077 IN destTransportAddress -- transport address to be used 1078 IN incomingMessage -- the message to send 1079 IN incomingMessageLength -- its length 1080 OUT tmStateReference 1081 ) 1083 statusInformation = 1084 openSession( 1085 IN transportDomain -- transport domain to be used 1086 IN transportAddress -- transport address to be used 1087 IN tmStateReference 1088 OUT sessionID 1089 ) 1091 statusInformation = 1092 closeSession( 1093 IN sessionID 1094 ) 1096 5. Cached Information and References 1098 The RFC3411 architecture uses caches to store dynamic model-specific 1099 information, and uses references in the ASIs to indicate in a model- 1100 independent manner which cached information must flow between 1101 subsytems. 1103 5.1. securityStateReference Cached Security Data 1105 From RFC3411: "For each message received, the Security Model caches 1106 the state information such that a Response message can be generated 1107 using the same security information, even if the Local Configuration 1108 Datastore is altered between the time of the incoming request and the 1109 outgoing response. 1111 A Message Processing Model has the responsibility for explicitly 1112 releasing the cached data if such data is no longer needed. To 1113 enable this, an abstract securityStateReference data element is 1114 passed from the Security Model to the Message Processing Model. The 1115 cached security data may be implicitly released via the generation of 1116 a response, or explicitly released by using the stateRelease 1117 primitive, as described in RFC3411 section 4.5.1." 1119 For the TMSM approach, the TMSP may need to provide the information 1120 to be stored in the securityStateReference to the message processing 1121 model. such as the security-model-independent securityName, 1122 securityLevel, and securityModel parameters. For responses, the 1123 messaging model may need to pass the parameters back to the TMSP. 1125 This document will differentiate the tmStateReference provided by the 1126 TMSP to the MPSP, from the securityStateReference provided by the 1127 MPSP to the Dispatcher. This document does not specify an 1128 implementation strategy, only an abstract discussion of the data that 1129 must flow between subsystems. An implementation MAY use one cache 1130 and one reference to serve both functions, but an implementer must be 1131 aware of the cache-release issues to prevent the cache from being 1132 released before the transport mapping has had an opportunity to 1133 extract the information it needs. 1135 5.2. tmStateReference Cached Security Data 1137 A tmStateReference is used to pass data between the TMSP and the 1138 MPSP, similar to the securityStateReference described in RFC3412. A 1139 reference to this cache can be envisioned as being appended to the 1140 ASIs between the TM and the MP. 1142 The TMSP may provide only some aspects of security, and leave some 1143 aspects to the MPSP. tmStateReference should be used to pass any 1144 parameters, in a model- and mechanism-specific format, that will be 1145 needed to coordinate the activities of the TMSP and MPSP, plus the 1146 parameters subsequently passed in securityStateReference. For 1147 example, the TMSP may provide privacy and data integrity and 1148 authentication and authorization policy retrievals, or some subset of 1149 these features, depending on the features available in the transport 1150 mechanisms. A field in tmStateReference should identify which 1151 services were provided for each received message by the TMSP, the 1152 securityLevel applied to the received message, the model-specific 1153 security identity, the session identifier for session based transport 1154 security, and so on. 1156 6. Integration with the SNMPv3 Message Format 1158 TMSM proposals can use the SNMPv3 message format, defined in RFC3412, 1159 section 6. This section discusses how the fields could be reused. 1161 6.1. msgVersion 1163 For proposals that reuse the SNMPv3 message format, this field should 1164 contain the value 3. 1166 6.2. msgGlobalData 1168 The fields msgID and msgMaxSize are used identically for the TMSM 1169 models as for the USM model. 1171 The msgSecurityModel field should be set to a value from the 1172 SnmpSecurityModel enumeration [RFC3411] to identify the specific TMSM 1173 model. Each standards-track TMSM model should have an enumeration 1174 assigned by IANA. Each enterprise-specific security model should 1175 have an enumeration assigned following instructions in the 1176 description of the SnmpSecurityModel TEXTUAL-CONVENTION from RFC3411. 1178 The msgSecurityParameters field would carry security information 1179 required for message security processing. It is unclear whether this 1180 field would be useful or what parameters would be carried to support 1181 security, since message security is provided by an external process, 1182 and msgSecurityParameters are not used by the access control 1183 subsystem. 1185 RFC3412 defines two primitives, generateRequestMsg() and 1186 processIncomingMsg() which require the specification of an 1187 authoritative SNMP entity. [discuss] We need to discuss what the 1188 meaning of authoritative would be in a TMSM environment, whether the 1189 specific services provided in USM security from msgSecurityParameters 1190 still are needed, and how the Message Processing model provides this 1191 information to the security model via generateRequestMsg() and 1192 processIncomingMsg() primitives. RFC3412 specifies that "The data in 1193 the msgSecurityParameters field is used exclusively by the Security 1194 Model, and the contents and format of the data is defined by the 1195 Security Model. This OCTET STRING is not interpreted by the v3MP, 1196 but is passed to the local implementation of the Security Model 1197 indicated by the msgSecurityModel field in the message." 1199 The msgFlags have the same values for the TMSM models as for the USM 1200 model. "The authFlag and privFlag fields indicate the securityLevel 1201 that was applied to the message before it was sent on the wire." 1203 6.3. securityLevel and msgFlags 1205 For an outgoing message, msgFlags is the requested security for the 1206 message; if a TMSM cannot provide the requested securityLevel, the 1207 model MUST describe a standard behavior that is followed for that 1208 situation. If the TMSM cannot provide at least the requested level 1209 of security, the TMSM MUST discard the request and SHOULD notify the 1210 message processing model that the request failed. 1212 [discuss] how is yet to be determined, and may be model-specific or 1213 implementation-specific. 1215 For an outgoing message, if the TMSM is able to provide stronger than 1216 requested security, that may be acceptable. The transport layer 1217 protocol would need to indicate to the receiver what security has 1218 been applied to the actual message. To avoid the need to mess with 1219 the ASN.1 encoding, the SNMPv3 message carries the requested 1220 msgFlags, not the actual securityLevel applied to the message. If a 1221 message format other than SNMPv3 is used, then the new message may 1222 carry the more accurate securityLevel in the SNMP message. 1224 For an incoming message, the receiving TMSM knows what must be done 1225 to process the message based on the transport layer mechanisms. If 1226 the underlying transport security mechanisms for the receiver cannot 1227 provide the matching securityLevel, then the message should follow 1228 the standard behaviors for the transport security mechanism, or be 1229 discarded silently. 1231 Part of the responsibility of the TMSM is to ensure that the actual 1232 security provided by the underlying transport layer security 1233 mechanisms is configured to meet or exceed the securityLevel required 1234 by the msgFlags in the SNMP message. When the MPSP processes the 1235 incoming message, it should compare the msgFlags field to the 1236 securityLevel actually provided for the message by the transport 1237 layer security. If they differ, the MPSP should determine whether 1238 the changed securityLevel is acceptable. If not, it should discard 1239 the message. Depending on the model, the MPSP may issue a reportPDU 1240 with the XXXXXXX model-specific counter. 1242 7. 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: 1250 tmSecurityStateReference - the unique identifier for the cached 1251 information 1252 tmTransportDomain 1253 tmTransportAddress 1254 tmSecurityModel - an indicator of which mechanisms to use 1255 tmSecurityName - a model-specific identifier of the security 1256 principal 1257 tmSecurityLevel - an indicator of which security services are 1258 requested 1259 A tmStateReference cache may contain additional information such as 1260 tmSessionID 1261 tmSessionKey 1262 tmSessionMsgID 1264 8. Prepare Data Elements from an Incoming SNMP Message 1266 For an incoming message, the TMSP will need to put information from 1267 the transport mechanisms used into the tmStateReference so the MPSP 1268 can extract the information and add it conceptually to the 1269 securityStateReference. 1271 The tmStateReference cache will likely contain at least the following 1272 information: 1273 tmStateReference - a unique identifier for the cached information 1274 tmSecurityStateReference - the unique identifier for the cached 1275 information 1276 tmTransportDomain 1277 tmTransportAddress 1278 tmSecurityModel - an indicator of which mechanisms to use 1279 tmSecurityName - a model-specific identifier of the security 1280 principal 1281 tmSecurityLevel - an indicator of which security services are 1282 requested 1283 tmAuthProtocol 1284 tmPrivProtocol 1285 and may contain additional information such as 1286 tmSessionID 1287 tmSessionKey 1288 tmSessionMsgID 1290 9. Notifications 1292 For notifications, if the cache has been released and then session 1293 closed, then the MPSP will request the TMSP to establish a session, 1294 populate the cache, and pass the securityStateReference to the MPSP. 1296 [discuss] We need to determine what state needs to be saved here. 1298 10. The TMSM MIB Module 1300 This memo defines a portion of the Management Information Base (MIB) 1301 for managing sessions in the Transport Mapping Security Model 1302 extension. 1304 10.1. Structure of the MIB Module 1306 Objects in this MIB module are arranged into subtrees. Each subtree 1307 is organized as a set of related objects. The overall structure and 1308 assignment of objects to their subtrees, and the intended purpose of 1309 each subtree, is shown below. 1311 10.1.1. The tmsmNotifications Subtree 1313 This subtree contains notifications to alert other entities to events 1314 that are applicable to all security models based on the Transport 1315 Mapping Security Model extension. 1317 10.1.2. The tmsmStats Subtree 1319 This subtree contains security-model-independent counters which are 1320 applicable to all security models based on the .Transport Mapping 1321 Security Model extension. This subtree provides information for 1322 identifying fault conditions and performance degradation. 1324 10.1.3. The tmsmSession Subtree 1326 This subtree contains security-model-independent information about 1327 sessions which are applicable to all security models based on the 1328 Transport Mapping Security Model extension. 1330 10.2. Relationship to Other MIB Modules 1332 Some management objects defined in other MIB modules are applicable 1333 to an entity implementing this MIB. In particular, it is assumed 1334 that an entity implementing the TMSM-MIB module will also implement 1335 the SNMPv2-MIB [RFC3418]. 1337 This MIB module is expected to be used with the MIB modules defined 1338 for managing specific security models that are based on the TMSM 1339 extension. This MIB module is designed to be security-model 1340 independent, and contains objects useful for managing common aspects 1341 of any TMSM-based security model. Specific security models may 1342 define a MIB module to contain security-model-dependent information. 1344 10.2.1. Textual Conventions 1346 Generic and Common Textual Conventions used in this document can be 1347 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1349 10.2.2. MIB Modules Required for IMPORTS 1351 The following MIB module imports items from [RFC2578], [RFC2579], 1352 [RFC2580], [RFC3411], and [RFC3419] 1354 11. Definitions 1356 TMSM-MIB DEFINITIONS ::= BEGIN 1358 IMPORTS 1359 MODULE-IDENTITY, OBJECT-TYPE, 1360 mib-2, Integer32, Unsigned32, Gauge32 1361 FROM SNMPv2-SMI 1362 TestAndIncr, StorageType, RowStatus 1363 FROM SNMPv2-TC 1364 MODULE-COMPLIANCE, OBJECT-GROUP 1365 FROM SNMPv2-CONF 1366 SnmpSecurityModel, 1367 SnmpAdminString, SnmpSecurityLevel, SnmpEngineID 1368 FROM SNMP-FRAMEWORK-MIB 1369 TransportAddress, TransportAddressType 1370 FROM TRANSPORT-ADDRESS-MIB 1371 ; 1373 tmsmMIB MODULE-IDENTITY 1374 LAST-UPDATED "200604200000Z" 1375 ORGANIZATION "ISMS Working Group" 1376 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1377 Subscribe: isms-request@lists.ietf.org 1379 Chairs: 1380 Juergen Quittek 1381 NEC Europe Ltd. 1382 Network Laboratories 1383 Kurfuersten-Anlage 36 1384 69115 Heidelberg 1385 Germany 1386 +49 6221 90511-15 1387 quittek@netlab.nec.de 1389 Juergen Schoenwaelder 1390 International University Bremen 1391 Campus Ring 1 1392 28725 Bremen 1393 Germany 1394 +49 421 200-3587 1395 j.schoenwaelder@iu-bremen.de 1397 Editor: 1398 David Harrington 1399 FutureWei Technologies 1400 1700 Alma Drive, Suite 100 1401 Plano, Texas 75075 1402 USA 1403 +1 603-436-8634 1404 dharrington@huawei.com 1405 " 1406 DESCRIPTION "The Transport Mapping Security Model 1407 MIB 1409 Copyright (C) The Internet Society (2006). This 1410 version of this MIB module is part of RFC XXXX; 1411 see the RFC itself for full legal notices. 1412 -- NOTE to RFC editor: replace XXXX with actual RFC number 1413 -- for this document and remove this note 1414 " 1416 REVISION "200604200000Z" -- 20 April 2006 1417 DESCRIPTION "The initial version, published in RFC XXXX. 1418 -- NOTE to RFC editor: replace XXXX with actual RFC number 1419 -- for this document and remove this note 1420 " 1422 ::= { mib-2 xxxx } 1423 -- RFC Ed.: replace xxxx with IANA-assigned number and 1424 -- remove this note 1426 -- ---------------------------------------------------------- -- 1427 -- subtrees in the TMSM-MIB 1428 -- ---------------------------------------------------------- -- 1430 tmsmNotifications OBJECT IDENTIFIER ::= { tmsmMIB 0 } 1431 tmsmObjects OBJECT IDENTIFIER ::= { tmsmMIB 1 } 1432 tmsmConformance OBJECT IDENTIFIER ::= { tmsmMIB 2 } 1434 -- ------------------------------------------------------------- 1435 -- Objects 1436 -- ------------------------------------------------------------- 1438 -- Textual Conventions 1439 SessionIndex ::= TEXTUAL-CONVENTION 1440 DISPLAY-HINT "d" 1441 STATUS current 1442 DESCRIPTION 1443 "A unique value, greater than zero, identifying a transport 1444 mapping security model session. The value must remain 1445 constant for the duration of a session. New values should 1446 be assigned in such a way that reuse of recently used 1447 values is avoided." 1448 SYNTAX Integer (1..2147483647) 1450 SessionIndexOrZero TEXTUAL-CONVENTION 1451 DISPLAY-HINT "d" 1452 STATUS current 1453 DESCRIPTION 1454 "This extension of the TmsmSessionId permits the additional 1455 value zero. The meaning of the value zero is object-specific 1456 and must therefore be defined as part of the description of 1457 any object which uses this syntax. Examples of the usage of 1458 zero might include situations where a session was unknown 1459 or where none or all sessions need to be referenced." 1460 SYNTAX Integer (0..2147483647) 1462 -- Notifications for the Transport Model Security Model extension 1464 -- Statistics for the Transport Model Security Model extension 1466 tmsmStats OBJECT IDENTIFIER ::= { tmsmObjects 1 } 1468 tmsmSessionOpenErrors OBJECT-TYPE 1469 SYNTAX Counter32 1470 MAX-ACCESS read-only 1471 STATUS current 1472 DESCRIPTION "The number of times an openSession() request 1473 failed to open a Session. 1474 " 1475 ::= { tmsmStats 1 } 1477 -- The tmsmSession Group 1479 tmsmSession OBJECT IDENTIFIER ::= { tmsmObjects 2 } 1481 tmsmSessionSpinLock OBJECT-TYPE 1482 SYNTAX TestAndIncr 1483 MAX-ACCESS read-write 1484 STATUS current 1485 DESCRIPTION "An advisory lock used to allow several cooperating 1486 TMSM security models to coordinate their 1487 use of facilities to create sessions in the 1488 tmsmSessionTable. 1489 " 1490 ::= { tmsmSession 1 } 1492 tmsmSessionCurrent OBJECT-TYPE 1493 SYNTAX Gauge32 1494 MAX-ACCESS read-only 1495 STATUS current 1496 DESCRIPTION "The current number of open sessions. 1497 " 1498 ::= { tmsmSession 2 } 1500 tmsmSessionMaxSupported OBJECT-TYPE 1501 SYNTAX Unsigned32 1502 MAX-ACCESS read-only 1503 STATUS current 1504 DESCRIPTION "The maximum number of open sessions supported. 1505 The value zero indicates the maximum is dynamic. 1506 " 1507 ::= { tmsmSession 3 } 1509 tmsmSessionOpenErrors OBJECT-TYPE 1510 SYNTAX Counter32 1511 MAX-ACCESS read-only 1512 STATUS current 1513 DESCRIPTION "The number of times an openSession() request 1514 failed to open a Session. 1515 " 1516 ::= { tmsmSession 4 } 1518 tmsmSessionSecurityLevelNotAvailableErrors OBJECT-TYPE 1519 SYNTAX Counter32 1520 MAX-ACCESS read-only 1521 STATUS current 1522 DESCRIPTION "The number of times an outgoing message was 1523 discarded because a requested securityLevel could not 1524 provided. 1525 " 1526 ::= { tmsmSession 5 } 1528 tmsmSessionTable OBJECT-TYPE 1529 SYNTAX SEQUENCE OF TmsmSessionEntry 1530 MAX-ACCESS not-accessible 1531 STATUS current 1532 DESCRIPTION "The table of currently available sessions configured 1533 in the SNMP engine's Local Configuration Datastore 1534 (LCD). 1536 Sessions are created as needed, and do not persist 1537 across network management system reboots. 1538 " 1539 ::= { tmsmSession 6 } 1541 tmsmSessionEntry OBJECT-TYPE 1542 SYNTAX TmsmSessionEntry 1543 MAX-ACCESS not-accessible 1544 STATUS current 1545 DESCRIPTION "A session configured in the SNMP engine's Local 1546 Configuration Datastore (LCD) for Transport Mapping 1547 Security Models. 1549 " 1550 INDEX { tmsmSessionID } 1551 ::= { tmsmSessionTable 1 } 1553 TmsmSessionEntry ::= SEQUENCE 1554 { 1555 tmsmSessionID SessionIndex, 1556 tmsmSessionTransport TransportAddressType, 1557 tmsmSessionAddress TransportAddress, 1558 tmsmSessionSecurityModel SnmpSecurityModel, 1559 tmsmSessionSecurityName SnmpAdminString, 1560 tmsmSessionSecurityLevel SnmpSecurityLevel, 1561 tmsmSessionEngineID SnmpEngineID 1562 } 1564 tmsmSessionID OBJECT-TYPE 1565 SYNTAX SessionIndex 1566 MAX-ACCESS not-accessible 1567 STATUS current 1568 DESCRIPTION "A locally-unique identifier for a session. 1569 " 1570 ::= { tmsmSessionEntry 1 } 1572 tmsmSessionTransport OBJECT-TYPE 1573 SYNTAX TransportAddressType 1574 MAX-ACCESS read-only 1575 STATUS current 1576 DESCRIPTION "The transport domain associated with this session. 1577 " 1578 ::= { tmsmSessionEntry 2 } 1580 tmsmSessionAddress OBJECT-TYPE 1581 SYNTAX TransportAddress 1582 MAX-ACCESS read-only 1583 STATUS current 1584 DESCRIPTION "The transport address associated with this session. 1585 " 1586 ::= { tmsmSessionEntry 3 } 1588 tmsmSessionSecurityModel OBJECT-TYPE 1589 SYNTAX SnmpSecurityModel 1590 MAX-ACCESS read-only 1591 STATUS current 1592 DESCRIPTION "The Security Model associated with this session." 1593 ::= { tmsmSessionEntry 4 } 1595 tmsmSessionSecurityName OBJECT-TYPE 1596 SYNTAX SnmpAdminString 1597 MAX-ACCESS read-only 1598 STATUS current 1599 DESCRIPTION "A human readable string representing the principal 1600 in Security Model independent format. 1601 " 1602 ::= { tmsmSessionEntry 5 } 1604 tmsmSessionSecurityLevel OBJECT-TYPE 1605 SYNTAX SnmpSecurityLevel 1606 MAX-ACCESS read-only 1607 STATUS current 1608 DESCRIPTION "The Level of Security at which SNMP messages can be 1609 sent using this session, in particular, one of: 1611 noAuthNoPriv - without authentication and 1612 without privacy, 1613 authNoPriv - with authentication but 1614 without privacy, 1615 authPriv - with authentication and 1616 with privacy. 1617 " 1618 DEFVAL { authPriv } 1619 ::= { tmsmSessionEntry 6 } 1621 tmsmSessionEngineID OBJECT-TYPE 1622 SYNTAX SnmpEngineID 1623 MAX-ACCESS read-only 1624 STATUS current 1625 DESCRIPTION "The administratively-unique identifier for the 1626 remote SNMP engine associated with this session. 1627 " 1629 ::= { tmsmSessionEntry 7 } 1631 -- ------------------------------------------------------------- 1632 -- tmsmMIB - Conformance Information 1633 -- ------------------------------------------------------------- 1635 tmsmGroups OBJECT IDENTIFIER ::= { tmsmConformance 1 } 1637 tmsmCompliances OBJECT IDENTIFIER ::= { tmsmConformance 2 } 1639 -- ------------------------------------------------------------- 1640 -- Units of conformance 1641 -- ------------------------------------------------------------- 1642 tmsmGroup OBJECT-GROUP 1643 OBJECTS { 1644 tmsmSessionOpenErrors, 1645 tmsmSessionSecurityLevelNotAvailableErrors, 1646 tmsmSessionCurrent, 1647 tmsmSessionMaxSupported, 1648 tmsmSessionTransport, 1649 tmsmSessionAddress, 1650 tmsmSessionSecurityModel, 1651 tmsmSessionSecurityName, 1652 tmsmSessionSecurityLevel, 1653 tmsmSessionEngineID, 1654 tmsmSessionSpinLock 1655 } 1656 STATUS current 1657 DESCRIPTION "A collection of objects for maintaining session 1658 information of an SNMP engine which implements the 1659 TMSM architectural extension. 1660 " 1662 ::= { tmsmGroups 2 } 1664 -- ------------------------------------------------------------- 1665 -- Compliance statements 1666 -- ------------------------------------------------------------- 1668 tmsmCompliance MODULE-COMPLIANCE 1669 STATUS current 1670 DESCRIPTION 1671 "The compliance statement for SNMP engines that support the 1672 TMSM-MIB" 1673 MODULE 1674 MANDATORY-GROUPS { tmsmGroup } 1675 ::= { tmsmCompliances 1 } 1677 END 1679 12. Security Considerations 1681 This document describes an architectural approach and multiple 1682 proposed configurations that would permit SNMP to utilize transport 1683 layer security services. Each section containing a proposal should 1684 discuss the security considerations of that approach. 1686 It is considered desirable by some industry segments that SNMP 1687 security models should utilize transport layer security that 1688 addresses perfect forward secrecy at least for encryption keys. 1689 Perfect forward secrecy guarantees that compromise of long term 1690 secret keys does not result in disclosure of past session keys. 1692 There are a number of management objects defined in this MIB module 1693 with a MAX-ACCESS clause of read-write and/or read-create. Such 1694 objects may be considered sensitive or vulnerable in some network 1695 environments. The support for SET operations in a non-secure 1696 environment without proper protection can have a negative effect on 1697 network operations. These are the tables and objects and their 1698 sensitivity/vulnerability: 1699 o [discuss] Should it be possible for a manager to create or modify 1700 rows in the session table? If so, then we may need the rowstatus 1701 object. If the session table is read-only then we can probably 1702 eliminate the rowstatus. If the tabel is not read-only, then we 1703 need to list the tables and objects and state why they are 1704 sensitive. 1706 There are no management objects defined in this MIB module that have 1707 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1708 MIB module is implemented correctly, then there is no risk that an 1709 intruder can alter or create any management objects of this MIB 1710 module via direct SNMP SET operations. 1712 Some of the readable objects in this MIB module (i.e., objects with a 1713 MAX-ACCESS other than not-accessible) may be considered sensitive or 1714 vulnerable in some network environments. It is thus important to 1715 control even GET and/or NOTIFY access to these objects and possibly 1716 to even encrypt the values of these objects when sending them over 1717 the network via SNMP. These are the tables and objects and their 1718 sensitivity/vulnerability: 1720 o [todo] list the tables and objects and state why they are 1721 sensitive. 1723 [discuss] how do we modify this section for an SNMP/SSH or other 1724 transport mapping security model? If the security model provides for 1725 securityName/Level/Model then some of the normal boilerplate is not 1726 true. 1728 SNMP versions prior to SNMPv3 did not include adequate security. 1729 Even if the network itself is secure (for example by using IPSec), 1730 even then, there is no control as to who on the secure network is 1731 allowed to access and GET/SET (read/change/create/delete) the objects 1732 in this MIB module. 1734 It is RECOMMENDED that implementers consider the security features as 1735 provided by the SNMPv3 framework (see [RFC3410], section 8), 1736 including full support for the SNMPv3 cryptographic mechanisms (for 1737 authentication and privacy). 1739 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1740 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1741 enable cryptographic security. It is then a customer/operator 1742 responsibility to ensure that the SNMP entity giving access to an 1743 instance of this MIB module is properly configured to give access to 1744 the objects only to those principals (users) that have legitimate 1745 rights to indeed GET or SET (change/create/delete) them. 1747 13. IANA Considerations 1749 The MIB module in this document uses the following IANA-assigned 1750 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1752 Descriptor OBJECT IDENTIFIER value 1753 ---------- ----------------------- 1755 tmsmMIB { mib-2 XXXX } 1757 Editor's Note (to be removed prior to publication): the IANA is 1758 requested to assign a value for "XXXX" under the 'mib-2' subtree 1759 and to record the assignment in the SMI Numbers registry. When 1760 the assignment has been made, the RFC Editor is asked to replace 1761 "XXXX" (here and in the MIB module) with the assigned value and to 1762 remove this note. 1764 [discuss] How do we add a new TransportType? 1766 14. Acknowledgments 1768 The Integrated Security for SNMP WG would like to thank the following 1769 people for their contributions to the process: 1771 The authors of submitted security model proposals: Chris Elliot, Wes 1772 Hardaker, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave 1773 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1775 The members of the Protocol Evaluation Team: Uri Blumenthal, 1776 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1778 WG members who committed to and performed detailed reviews: Jeffrey 1779 Hutzelman 1781 15. References 1783 15.1. Normative References 1785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1786 Requirement Levels", BCP 14, RFC 2119, March 1997. 1788 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1789 (SASL)", RFC 2222, October 1997. 1791 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1792 and T. Wright, "Transport Layer Security (TLS) 1793 Extensions", RFC 4366, April 2006. 1795 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1796 Schoenwaelder, Ed., "Structure of Management Information 1797 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1799 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1800 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1801 STD 58, RFC 2579, April 1999. 1803 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1804 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1805 April 1999. 1807 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1808 "Remote Authentication Dial In User Service (RADIUS)", 1809 RFC 2865, June 2000. 1811 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1812 Architecture for Describing Simple Network Management 1813 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1814 December 2002. 1816 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1817 "Message Processing and Dispatching for the Simple Network 1818 Management Protocol (SNMP)", STD 62, RFC 3412, 1819 December 2002. 1821 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1822 (USM) for version 3 of the Simple Network Management 1823 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1825 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1826 Management Protocol (SNMP)", STD 62, RFC 3417, 1827 December 2002. 1829 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1830 Simple Network Management Protocol (SNMP)", STD 62, 1831 RFC 3418, December 2002. 1833 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 1834 Transport Addresses", RFC 3419, December 2002. 1836 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1837 Protocol Architecture", RFC 4251, January 2006. 1839 15.2. Informative References 1841 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1842 "Introduction and Applicability Statements for Internet- 1843 Standard Management Framework", RFC 3410, December 2002. 1845 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1846 Management Protocol (SNMP) Applications", STD 62, 1847 RFC 3413, December 2002. 1849 [I-D.ietf-netconf-ssh] 1850 Wasserman, M. and T. Goddard, "Using the NETCONF 1851 Configuration Protocol over Secure Shell (SSH)", 1852 draft-ietf-netconf-ssh-06 (work in progress), March 2006. 1854 Appendix A. Parameter Table 1856 Following is a CSV formatted matrix useful for tracking data flows 1857 into and out of the dispatcher, message, and security subsystems. 1858 Import this into your favorite spreadsheet or other CSV compatible 1859 application. You will need to remove lines feeds from the second and 1860 third lines, which needed to be wrapped to fit into RFC limits. 1862 A.1. ParameterList.csv 1864 ,Dispatcher,,,,Messaging,,,Security,, 1866 ,sendPdu,returnResponse,processPdu,processResponse 1867 ,prepareOutgoingMessage,prepareResponseMessage,prepareDataElements 1868 ,generateRequest,processIncoming,generateResponse 1870 transportDomain,In,,,,In,,In,,, 1872 transportAddress,In,,,,In,,In,,, 1874 destTransportDomain,,,,,Out,Out,,,, 1876 destTransportAddress,,,,,Out,Out,,,, 1878 messageProcessingModel,In,In,In,In,In,In,Out,In,In,In 1880 securityModel,In,In,In,In,In,In,Out,In,In,In 1882 securityName,In,In,In,In,In,In,Out,In,Out,In 1884 securityLevel,In,In,In,In,In,In,Out,In,In,In 1886 contextEngineID,In,In,In,In,In,In,Out,,, 1888 contextName,In,In,In,In,In,In,Out,,, 1890 expectResponse,In,,,,In,,,,, 1892 PDU,In,In,In,In,In,In,Out,,, 1894 pduVersion,In,In,In,In,In,In,Out,,, 1896 statusInfo,Out,In,,In,,In,Out,Out,Out,Out 1898 errorIndication,Out,Out,,,,,Out,,, 1900 sendPduHandle,Out,,,In,In,,Out,,, 1902 maxSizeResponsePDU,,In,In,,,In,Out,,Out, 1904 stateReference,,In,In,,,In,Out,,, 1906 wholeMessage,,,,,Out,Out,,Out,In,Out 1907 messageLength,,,,,Out,Out,,Out,In,Out 1909 maxMessageSize,,,,,,,,In,In,In 1911 globalData,,,,,,,,In,,In 1913 securityEngineID,,,,,,,,In,Out,In 1915 scopedPDU,,,,,,,,In,Out,In 1917 securityParameters,,,,,,,,Out,,Out 1919 securityStateReference,,,,,,,,,Out,In 1921 pduType,,,,,,,Out,,, 1923 tmStateReference,,,,,,Out,In,,In, 1925 Appendix B. Why tmSecurityReference? 1927 This appendix considers why a cache-based approach was selected for 1928 passing parameters. This section may be removed from subsequent 1929 revisions fo the document. 1931 There are four approaches that could be used for passing information 1932 between the TMSP and an MPSP. 1934 1. one could define an ASI to supplement the existing ASIs, or 1935 2. the TMSM could add a header to encapsulate the SNMP message, 1936 3. the TMSM could utilize fields already defined in the existing 1937 SNMPv3 message, or 1938 4. the TMSM could pass the information in an implementation-specific 1939 cache or via a MIB module. 1941 B.1. Define an Abstract Service Interface 1943 Abstract Service Interfaces (ASIs) [RFC3411] are defined by a set of 1944 primitives that specify the services provided and the abstract data 1945 elements that are to be passed when the services are invoked. 1946 Defining additional ASIs to pass the security and transport 1947 information from the transport mapping to a messaging security model 1948 has the advantage of being consistent with existing RFC3411/3412 1949 practice, and helps to ensure that any TMSM proposals pass the 1950 necessary data, and do not cause side effects by creating model- 1951 specific dependencies between itself and other models or other 1952 subsystems other than those that are clearly defined by an ASI. 1954 B.2. Using an Encapsulating Header 1956 A header could encapsulate the SNMP message to pass necessary 1957 information from the TMSP to the dispatcher and then to a messaging 1958 security model. The message header would be included in the 1959 wholeMessage ASI parameter, and would be removed by a corresponding 1960 messaging model. This would imply the (one and only) messaging 1961 dispatcher would need to be modified to determine which SNMP message 1962 version was involved, and a new message processing model would need 1963 to be developed that knew how to extract the header from the message 1964 and pass it to the MPSP. 1966 B.3. Modifying Existing Fields in an SNMP Message 1968 [RFC3412] describes the SNMPv3 message, which contains fields to pass 1969 security related parameters. The TMSM could use these fields in an 1970 SNMPv3 message, or comparable fields in other message formats to pass 1971 information between transport mapping security models in different 1972 SNMP engines, and to pass information between a transport mapping 1973 security model and a corresponding messaging security model. 1975 If the fields in an incoming SNMPv3 message are changed by the TMSP 1976 before passing it to the MPSP, then the TMSP will need to decode the 1977 ASN.1 message, modify the fields, and re-encode the message in ASN.1 1978 before passing the message on to the message dispatcher or to the 1979 transport layer. This would require an intimate knowledge of the 1980 message format and message versions so the TMSP knew which fields 1981 could be modified. This would seriously violate the modularity of 1982 the architecture. 1984 B.4. Using a Cache 1986 This document describes a cache, into which the TMSP puts information 1987 about the security applied to an incoming message, and an MPSP 1988 extracts that information from the cache. Given that there may be 1989 multiple TM-security caches, a tmStateReference is passed as an extra 1990 parameter in the ASIs between the transport mapping and the messaging 1991 security model.so the MPSP knows which cache of information to 1992 consult. 1994 This approach does create dependencies between a model-specific TMSP 1995 and a corresponding specific MPSP. This approach of passing a model- 1996 independent reference is consistent with the securityStateReference 1997 cache already being passed around in the RFC3411 ASIs. 1999 Appendix C. Open Issues 2000 Appendix D. Change Log 2002 NOTE to RFC editor: Please remove this change log before publishing 2003 this document as an RFC. 2005 Changes from revision -01- to -02- 2007 o wrote text for session establishment requirements section. 2008 o wrote text for session maintenance requirements section. 2009 o removed section on relation to SNMPv2-MIB 2010 o updated MIB module to pass smilint 2011 o Added Structure of the MIB module, and other expected MIB-related 2012 sections. 2013 o updated author address 2014 o corrected spelling 2015 o removed msgFlags appendix 2016 o Removed section on implementation considerations. 2017 o started modifying the security boilerplate to address TMSM and MIB 2018 security issues 2019 o reorganized slightly to better separate requirements from proposed 2020 solution. This probably needs additional work. 2021 o removed section with sample protocols and sample tmStateReference. 2022 o Added section for acronyms 2023 o moved section comparing parameter passing techniques to appendix. 2024 o Removed section on notification requirements. 2026 Changes from revision -00- 2027 o changed SSH references from I-Ds to RFCs 2028 o removed parameters from tmStateReference for DTLS that revealed 2029 lower layer info. 2030 o Added TMSM-MIB module 2031 o Added Internet-Standard Management Framework boilerplate 2032 o Added Structure of the MIB Module 2033 o Added MIB security considerations boilerplate (to be completed) 2034 o Added IANA Considerations 2035 o Added ASI Parameter table 2036 o Added discussion of Sessions 2037 o Added Open issues and Change Log 2038 o Rearranged sections 2040 Authors' Addresses 2042 David Harrington 2043 Futurewei Technologies 2044 1700 Alma Dr. Suite 100 2045 Plano, TX 75075 2046 USA 2048 Phone: +1 603 436 8634 2049 EMail: dharrington@huawei.com 2051 Juergen Schoenwaelder 2052 International University Bremen 2053 Campus Ring 1 2054 28725 Bremen 2055 Germany 2057 Phone: +49 421 200-3587 2058 EMail: j.schoenwaelder@iu-bremen.de 2060 Full Copyright Statement 2062 Copyright (C) The Internet Society (2006). 2064 This document is subject to the rights, licenses and restrictions 2065 contained in BCP 78, and except as set forth therein, the authors 2066 retain all their rights. 2068 This document and the information contained herein are provided on an 2069 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2070 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2071 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2072 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2073 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2074 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2076 Intellectual Property 2078 The IETF takes no position regarding the validity or scope of any 2079 Intellectual Property Rights or other rights that might be claimed to 2080 pertain to the implementation or use of the technology described in 2081 this document or the extent to which any license under such rights 2082 might or might not be available; nor does it represent that it has 2083 made any independent effort to identify any such rights. Information 2084 on the procedures with respect to rights in RFC documents can be 2085 found in BCP 78 and BCP 79. 2087 Copies of IPR disclosures made to the IETF Secretariat and any 2088 assurances of licenses to be made available, or the result of an 2089 attempt made to obtain a general license or permission for the use of 2090 such proprietary rights by implementers or users of this 2091 specification can be obtained from the IETF on-line IPR repository at 2092 http://www.ietf.org/ipr. 2094 The IETF invites any interested party to bring to its attention any 2095 copyrights, patents or patent applications, or other proprietary 2096 rights that may cover technology that may be required to implement 2097 this standard. Please address the information to the IETF at 2098 ietf-ipr@ietf.org. 2100 Acknowledgement 2102 Funding for the RFC Editor function is currently provided by the 2103 Internet Society.