idnits 2.17.1 draft-ietf-isms-tmsm-03.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 2028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2052. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 387 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 (June 23, 2006) is 6510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 3 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 Huawei Technologies (USA) 4 Intended status: Informational J. Schoenwaelder 5 Expires: December 25, 2006 International University Bremen 6 June 23, 2006 8 Transport Mapping Security Model (TMSM) Architectural Extension for the 9 Simple Network Management Protocol (SNMP) 10 draft-ietf-isms-tmsm-03.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 December 25, 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. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 23 75 4.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 24 76 4.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 26 77 4.1.2. msgSecurityParameters . . . . . . . . . . . . . . . . 27 78 5. Cached Information and References . . . . . . . . . . . . . . 27 79 5.1. tmSessionReference Cached Session Data . . . . . . . . . . 27 80 5.2. securityStateReference Cached Security Data . . . . . . . 27 81 6. Abstract Service Interfaces for TMSM . . . . . . . . . . . . . 28 82 6.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 29 83 6.2. TMSP for an Outgoing Message . . . . . . . . . . . . . . . 30 84 6.3. Processing an Incoming SNMP Message . . . . . . . . . . . 30 85 6.3.1. TMSP for an Incoming Message . . . . . . . . . . . . . 30 86 6.3.2. Prepare Data Elements from Incoming Messages . . . . . 31 87 6.3.3. MPSP for an Incoming Message . . . . . . . . . . . . . 32 88 7. The TMSM MIB Module . . . . . . . . . . . . . . . . . . . . . 33 89 7.1. Structure of the MIB Module . . . . . . . . . . . . . . . 33 90 7.1.1. The tmsmStats Subtree . . . . . . . . . . . . . . . . 33 91 7.2. Relationship to Other MIB Modules . . . . . . . . . . . . 33 92 7.2.1. Textual Conventions . . . . . . . . . . . . . . . . . 33 93 7.2.2. MIB Modules Required for IMPORTS . . . . . . . . . . . 33 94 7.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 33 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 97 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 40 101 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 41 102 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 41 103 Appendix B. Why tmSessionReference? . . . . . . . . . . . . . . . 42 104 B.1. Define an Abstract Service Interface . . . . . . . . . . . 43 105 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 43 106 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 43 107 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 44 108 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 44 109 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 44 111 1. Introduction 113 This document describes a Transport Mapping Security Model (TMSM) 114 extension for the Simple Network Management Protocol (SNMP) 115 architecture defined in [RFC3411]. This document identifies and 116 discusses some key aspects that need to be considered for any 117 transport-mapping-based security model for SNMP. 119 1.1. The Internet-Standard Management Framework 121 For a detailed overview of the documents that describe the current 122 Internet-Standard Management Framework, please refer to section 7 of 123 RFC 3410 [RFC3410]. 125 Managed objects are accessed via a virtual information store, termed 126 the Management Information Base or MIB. MIB objects are generally 127 accessed through the Simple Network Management Protocol (SNMP). 128 Objects in the MIB are defined using the mechanisms defined in the 129 Structure of Management Information (SMI). This memo specifies a MIB 130 module that is compliant to the SMIv2, which is described in STD 58, 131 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 132 [RFC2580]. 134 1.2. Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 Some points requiring further WG research and discussion are 141 identified by [discuss] markers in the text. Some points requiring 142 further editing by the editors are marked [todo] in the text. 144 1.3. Acronyms 146 This section contains a list of acronyms used within the document and 147 references to where in the document the acronym is defined, for easy 148 lookup. 149 o TMSM - a Transport Mapping Security Model 150 o SMSP - a Security Model Security Processor, the portion of a TMSM 151 security model that resides in the Message Processing subsystem of 152 an SNMPv3 engine. See Section 2.2.1 153 o TMSP - the Transport Mapping Security Processor, the portion of a 154 TMSM security model that resides in the Transport Mapping section 155 of the Dispatcher of an SNMPv3 engine. See Section 2.2.1 157 1.4. Motivation 159 There are multiple ways to secure one's home or business, in a 160 continuum of alternatives. Let's consider three general approaches. 161 In the first approach, an individual could buy a gun, learn to use 162 it, and sit on your front porch waiting for intruders. In the second 163 approach, one could hire an employee with a gun, schedule the 164 employee, position the employee to guard what you want protected, 165 hire a second guard to cover if the first gets sick, and so on. In 166 the third approach, you could hire a security company, tell them what 167 you want protected, and they could hire employees, train them, buy 168 the guns, position the guards, schedule the guards, send a 169 replacement when a guard cannot make it, etc., thus providing the 170 security you want, with no significant effort on your part other than 171 identifying requirements and verifying the quality of the service 172 being provided. 174 The User-based Security Model (USM) as defined in [RFC3414] largely 175 uses the first approach - it provides its own security. It utilizes 176 existing mechanisms (MD5=the gun), but provides all the coordination. 177 USM provides for the authentication of a principal, message 178 encryption, data integrity checking, timeliness checking, etc. 180 USM was designed to be independent of other existing security 181 infrastructures. USM therefore requires a separate principal and key 182 management infrastructure. Operators have reported that deploying 183 another principal and key management infrastructure in order to use 184 SNMPv3 is a deterrent to deploying SNMPv3. It is possible but 185 difficult to define external mechanisms that handle the distribution 186 of keys for use by the USM approach. 188 A solution based on the second approach might use a USM-compliant 189 architecture, but combine the authentication mechanism with an 190 external mechanism, such as RADIUS [RFC2865], to provide the 191 authentication service. It might be possible to utilize an external 192 protocol to encrypt a message, to check timeliness, to check data 193 integrity, etc. It is difficult to cobble together a number of 194 subcontracted services and coordinate them however, because it is 195 difficult to build solid security bindings between the various 196 services, and potential for gaps in the security is significant. 198 A solution based on the third approach might utilize one or more 199 lower-layer security mechanisms to provide the message-oriented 200 security services required. These would include authentication of 201 the sender, encryption, timeliness checking, and data integrity 202 checking. There are a number of IETF standards available or in 203 development to address these problems through security layers at the 204 transport layer or application layer, among them TLS [RFC4366], SASL 206 [RFC4422], and SSH [RFC4251]. 208 From an operational perspective, it is highly desirable to use 209 security mechanisms that can unify the administrative security 210 management for SNMPv3, command line interfaces (CLIs) and other 211 management interfaces. The use of security services provided by 212 lower layers is the approach commonly used for the CLI, and is also 213 the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. 215 This document proposes a Transport Mapping Security Model (TMSM) 216 extension to the RFC3411 architecture, that allows security to be 217 provided by an external protocol connected to the SNMP engine through 218 an SNMP transport-mapping [RFC3417]. Such a TMSM would then enable 219 the use of existing security mechanisms such as (TLS) [RFC4366] or 220 SSH [RFC4251] within the RFC3411 architecture. 222 There are a number of Internet security protocols and mechanisms that 223 are in wide spread use. Many of them try to provide a generic 224 infrastructure to be used by many different application layer 225 protocols. The motivation behind TMSM is to leverage these protocols 226 where it seems useful. 228 There are a number of challenges to be addressed to map the security 229 provided by a secure transport into the SNMP architecture so that 230 SNMP continues to work without any surprises. These challenges are 231 discussed in detail in this document. For some key issues, design 232 choices are discussed that may be made to provide a workable solution 233 that meets operational requirements and fits into the SNMP 234 architecture defined in [RFC3411]. 236 2. Requirements of a Transport Mapping Security Model 238 2.1. Message Security Requirements 240 Transport mapping security protocols SHOULD ideally provide the 241 protection against the following message-oriented threats [RFC3411]: 243 1. modification of information 244 2. masquerade 245 3. message stream modification 246 4. disclosure 248 According to [RFC3411], it is not required to protect against denial 249 of service or traffic analysis. 251 2.1.1. Security Protocol Requirements 253 There are a number of standard protocols that could be proposed as 254 possible solutions within the TMSM framework. Some factors should be 255 considered when selecting a protocol for use within this framework. 257 Using a protocol in a manner for which it was not designed has 258 numerous problems. The advertised security characteristics of a 259 protocol may depend on its being used as designed; when used in other 260 ways, it may not deliver the expected security characteristics. It 261 is recommended that any proposed model include a discussion of the 262 applicability statement of the protocols to be used. 264 A protocol used for the TMSM framework should ideally require no 265 modifications to the protocol. Modifying the protocol may change its 266 security characteristics in ways that would impact other existing 267 usages. If a change is necessary, the change should be an extension 268 that has no impact on the existing usages. It is recommended that 269 any proposed model include a discussion of potential impact on other 270 usages of the protocol. 272 It has been a long-standing requirement that SNMP be able to work 273 when the network is unstable, to enable network troubleshooting and 274 repair. The UDP approach has been considered to meet that need well, 275 with an assumption that getting small messages through, even if out 276 of order, is better than getting no messages through. There has been 277 a long debate about whether UDP actually offers better support than 278 TCP when the underlying IP or lower layers are unstable. There has 279 been recent discussion of whether operators actually use SNMP to 280 troubleshoot and repair unstable networks. 282 There has been discussion of ways SNMP could be extended to better 283 support management/monitoring needs when a network is running just 284 fine. Use of a TCP transport, for example, could enable larger 285 message sizes and more efficient table retrievals. 287 TMSM models MUST be able to coexist with other protocol models, and 288 may be designed to utilize either TCP or UDP, depending on the 289 transport. 291 2.2. SNMP Requirements 293 2.2.1. Architectural Modularity Requirements 295 SNMP version 3 (SNMPv3) is based on a modular architecture (described 296 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 297 standards over time, and to minimize side effects between subsystems 298 when changes are made. The architecture includes a Security 299 Subsystem which is responsible for realizing security services. 301 In SNMPv2, there were many problems of side effects between 302 subsystems caused by the manipulation of MIB objects, especially 303 those related to authentication and authorization, because many of 304 the parameters were stored in shared MIB objects, and different 305 models and protocols could assign different values to the objects. 306 Contributors assumed slightly different shades of meaning depending 307 on the models and protocols being used. As the shared MIB module 308 design was modified to accommodate a specific model, other models 309 which used the same MIB objects were broken. 311 Abstract Service Interfaces (ASIs) were developed to pass model- 312 independent parameters. The models were required to translate from 313 their model-dependent formats into a model-independent format, 314 defined using model-independent semantics, which would not impact 315 other models. 317 Parameters have been provided in the ASIs to pass model-independent 318 information about the authentication that has been provided. These 319 parameters include a model-independent identifier of the security 320 "principal", the security model used to perform the authentication, 321 and which SNMP-specific security features were applied to the message 322 (authentication and/or privacy). 324 Parameters have been provided in the ASIs to pass model-independent 325 transport address information. These parameters utilize the 326 TransportType and TransportAddress 328 The design of a transport mapping security model must abide the goals 329 of the RFC3411 architecture defined in [RFC3411]. To that end, this 330 transport mapping security model proposal uses a modular design that 331 can be advanced through the standards process independently of other 332 proposals, and independent of other modular components as much as 333 possible. 335 IETF standards typically require one mandatory to implement solution, 336 with the capability of adding new security mechanisms in the future. 337 Any transport mapping security model should define one minimum- 338 compliance mechanism, preferably one which is already widely deployed 339 within the transport layer security protocol used. 341 The TMSM architectural extension permits additional transport 342 security protocols to be "plugged into" the RFC3411 architecture, 343 supported by corresponding transport-security-aware transport mapping 344 models. 346 The RFC3411 architecture, and the USM approach, assume that a 347 security model is called by a message-processing model and will 348 perform multiple security functions. The TMSM approach performs 349 similar functions but performs them in different places within the 350 architecture, so we need to distinguish the two locations for 351 security processing. 353 Transport mapping security is by its very nature a security layer 354 which is plugged into the RFC3411 architecture between the transport 355 layer and the message dispatcher. Conceptually, transport mapping 356 security processing will be called from within the Transport Mapping 357 functionality of an SNMP engine dispatcher to perform the translation 358 of transport security parameters to/from security-model-independent 359 parameters. This transport mapping security processor will be 360 referred to in this document as TMSP. 362 Additional functionality may be performed as part of the message 363 processing function, i.e., in the security subsystem of the RFC3411 364 architecture. This document will refer to security model's security 365 processor as the SMSP. 367 Thus a TMSM is composed of both a TMSP and an SMSP. 369 +------------------------------+ 370 | Network | 371 +------------------------------+ 372 ^ ^ ^ 373 | | | 374 v v v 375 +-----+ +-----+ +-------+ 376 | UDP | | TCP | . . . | other | 377 +-----+ +-----+ +-------+ 378 ^ ^ ^ 379 | | | 380 v v v 381 +-----+ +-----+ +-------+ 382 | SSH | | TLS | . . . | other | 383 +-----+ +-----+ +-------+ (traditional SNMP agent) 384 +-------------------------------------------------------------------+ 385 | ^ | 386 | | | 387 | Dispatcher v | 388 | +-------------------+ | 389 | | Transport | +--------------+ | 390 | | Mapping |<---> | TMSM | | 391 | | (e.g., RFC 3417) | | TMSP | | 392 | | | +--------------+ | 393 | | | | 394 | | | +---------------------+ +----------------+ | 395 | | | | Message Processing | | Security | | 396 | | | | Subsystem | | Subsystem | | 397 | | | | +------------+ | | | | 398 | | | | +->| v1MP * |<--->| +------------+ | | 399 | | | | | +------------+ | | | Other | | | 400 | | | | | +------------+ | | | Security | | | 401 | | | | +->| v2cMP * |<--->| | Model | | | 402 | | Message | | | +------------+ | | +------------+ | | 403 | | Dispatcher <--------->| +------------+ | | +------------+ | | 404 | | | | +->| v3MP * |<--->| | TMSM | | | 405 | | | | | +------------+ | | | SMSP | | | 406 | | PDU Dispatcher | | | +------------+ | | | | | | 407 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 408 | ^ | +------------+ | | | | 409 | | +---------------------+ +----------------+ | 410 | v | 411 | +-------+-------------------------+---------------+ | 412 | ^ ^ ^ | 413 | | | | | 414 | v v v | 415 | +-------------+ +---------+ +--------------+ +-------------+ | 416 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 417 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 418 | | application | | | | applications | | application | | 419 | +-------------+ +---------+ +--------------+ +-------------+ | 420 | ^ ^ | 421 | | | | 422 | v v | 423 | +----------------------------------------------+ | 424 | | MIB instrumentation | SNMP entity | 425 +-------------------------------------------------------------------+ 427 2.2.1.1. USM and the RFC3411 Architecture 429 The following diagrams illustrate the difference in the security 430 processing done by the USM model and the security processing done by 431 a TMSM model. 433 The USM security model is encapsulated by the messaging model, 434 because the messaging model needs to perform the following steps (for 435 incoming messages) 436 1) decode the ASN.1 (messaging model) 437 2) determine the SNMP security model and parameters (messaging model) 438 3) decrypt the encrypted portions of the message (security model) 439 4) translate parameters to model-independent parameters (security 440 model) 441 5) determine which application should get the decrypted portions 442 (messaging model), and 443 6) pass on the decrypted portions with model-independent parameters. 445 The USM approach uses SNMP-specific message security and parameters. 447 | -----------------------------------------------| 448 | transport layer | 449 | -----------------------------------------------| 450 ^ 451 | 452 v 453 -------------------------------------------------- 454 | -----------------------------------------------| 455 | | transport mapping | 456 | -----------------------------------------------| 457 | ^ 458 | | 459 | v 460 | --------------------------------------------- | 461 | --------------------- ------------------ | 462 | SNMP messaging <--> | decryption + | | 463 | | translation | | 464 | --------------------- ------------------ | 465 | ^ 466 | | 467 | v 468 | --------------------- ------------------ | 469 | | SNMP applications | <--> | access control | | 470 | --------------------- ------------------ | 472 | --------------------------------------------- | 474 2.2.1.2. TMSM and the RFC3411 Architecture 476 In the TMSM approach, the order of the steps differ and may be 477 handled by different subsystems: 478 1) decrypt the encrypted portions of the message (transport layer) 479 2) determine the SNMP security model and parameters (transport 480 mapping) 481 3*) translate parameters to model-independent parameters (transport 482 mapping) 483 4) decode the ASN.1 (messaging model) 484 5) determine which application should get the decrypted portions 485 (messaging model) 486 6*) translate parameters to model-independent parameters (security 487 model) 488 7) pass on the decrypted portions with model-independent security 489 parameters 491 This is largely based on having non-SNMP-specific message security 492 and parameters. The transport mapping model might provide the 493 translation from e.g., an SSH user name to the securityName in step 494 3, OR the SSH user might be passed to the messaging model to pass to 495 a TMSM security model to do the translation in step 6, if the WG 496 decides all translations should use the same translation table (e.g., 497 the USM MIB). 499 | -----------------------------------------------| 500 | ------------------ | 501 | transport layer <--> | decryption | | 502 | ------------------ | 503 | -----------------------------------------------| 504 ^ 505 | 506 v 507 -------------------------------------------------- 508 | -----------------------------------------------| 509 | ------------------ | 510 | transport mapping <--> | translation* | | 511 | ------------------ | 512 | -----------------------------------------------| 513 | ^ 514 | | 515 | v 516 | --------------------------------------------- | 517 | ------------------ | 518 | SNMP messaging <--> | translation* | | 519 | ------------------ | 520 | --------------------- ------------------ | 521 | ^ 522 | | 523 | v 524 | --------------------- ------------------ | 525 | | SNMP applications | <--> | access control | | 526 | --------------------- ------------------ | 528 | --------------------------------------------- | 530 2.2.1.3. Passing Information between Engines 532 A TMSM model will establish an encrypted tunnel between the transport 533 mappings of two SNMP engines. One transport mapping security model 534 instance encrypts all messages, and the other transport mapping 535 security model instance decrypts the messages. 537 After the transport layer tunnel is established, then SNMP messages 538 can conceptually be sent through the tunnel from one SNMP message 539 dispatcher to another SNMP message dispatcher. Once the tunnel is 540 established, multiple SNMP messages may be able to be passed through 541 the same tunnel. 543 2.2.2. Access Control Requirements 545 2.2.2.1. securityName Binding 547 For SNMP access control to function properly, the security mechanism 548 must establish a securityModel identifier, a securityLevel, and a 549 securityName, which is the security model independent identifier for 550 a principal. The SNMPv3 message processing architecture subsystem 551 relies on a security model, such as USM, to play a role in security 552 that goes beyond protecting the message - it provides a mapping 553 between the USM-specific principal to a security-model independent 554 securityName which can be used for subsequent processing, such as for 555 access control. 557 The TMSM is a two-stage security model, with a transport mapping 558 security process (TMSP) and a security model security process (SMSP). 559 Depending on the design of the specific TMSM model, i.e., which 560 transport layer protocol is used, different features might be 561 provided by the TMSP or by the SMSP. For example, the translation 562 from a mechanism-specific authenticated identity to a securityName 563 might be done by the TMSP or by the SMSP. 565 The securityName MUST be bound to the mechanism-specific 566 authenticated identity, and this mapping MUST be done before the SMSP 567 portion of the model passes securityName to the message processing 568 model via the processIncoming() ASI. 570 The SNMP architecture distinguishes between messages with no 571 authentication and no privacy (noAuthNoPriv), authentication without 572 privacy (authNoPriv) and authentication with privacy (authPriv). 573 Hence, the authentication of a transport layer identity plays an 574 important role and must be considered by any TMSM, and principal 575 authentication must be available via the transport layer security 576 protocol. 578 If the type of authentication provided by the transport layer (e.g. 579 TLS) is considered adequate to secure and/or encrypt the message, but 580 inadequate to provide the desired granularity of access control (e.g. 581 user-based), then a second authentication (e.g., one provided by a 582 RADIUS server) may be used to provide the authentication identity 583 which is bound to the securityName. This approach would require a 584 good analysis of the potential for man-in-the-middle attacks or 585 masquerade possibilities. 587 2.2.2.2. Separation of Authentication and Authorization 589 A TMSM security model should take care to not violate the separation 590 of authentication and authorization in the RFC3411 architecture. The 591 isAccessAllowed() primitive is used for passing security-model 592 independent parameters between the subsystems of the architecture. 594 Mapping of (securityModel, securityName) to an access control policy 595 should be handled within the access control subsystem, not the 596 security subsystem, to be consistent with the modularity of the 597 RFC3411 architecture. This separation was a deliberate decision of 598 the SNMPv3 WG, to allow support for authentication protocols which 599 did not provide authorization capabilities, and to support 600 authorization schemes, such as VACM, that do not perform their own 601 authentication. 603 An authorization model MAY require authentication by certain 604 securityModels and a minimum securityLevel to allow access to the 605 data. 607 TMSM is an enhancement for the SNMPv3 privacy and authentication 608 provisions, but it is not a significant improvement for the 609 authorization needs of SNMPv3. TMSM provides all the model- 610 independent parameters for the isAccessAllowed() primitive [RFC3411]. 612 TMSM does not specify how the securityModel and securityName could be 613 dynamically mapped to a VACM-style groupName. The mapping of 614 (securityModel, securityName) to a groupName is a VACM-specific 615 mechanism for naming an access control policy, and for tying the 616 named policy to the addressing capabilities of the data modeling 617 language (e.g. SMIv2 [RFC2578]), the operations supported, and other 618 factors. Providing a binding outside the Access Control subsystem 619 might create dependencies that could make it harder to develop 620 alternate models of access control, such as one built on UNIX groups 621 or Windows domains. The preferred approach is to pass the model- 622 independent security parameters via the isAccessAllowed() ASI, and 623 perform the mapping within the access control model. 625 To provide support for protocols which simultaneously send 626 information for authentication and authorization, such as RADIUS 627 [RFC2865], model-specific authorization information MAY be cached or 628 otherwise made available to the access control subsystem, e.g., via a 629 MIB table similar to the vacmSecurityToGroupTable, so the access 630 control subsystem can create an appropriate binding between the 631 model-independent securityModel and securityName and a model-specific 632 access control policy. This may be highly undesirable, however, if 633 it creates a dependency between a security model and an access 634 control model, just as it is undesirable that the TMSM approach 635 creates a dependency between an SNMP message version and the security 636 provided by a transport mapping. 638 2.2.3. Security Parameter Passing Requirements 640 RFC3411 section 4 describes primitives to describe the abstract data 641 flows between the various subsystems, models and applications within 642 the architecture. Abstract Service Interfaces describe the flow of 643 data between subsystems within an engine. The ASIs generally pass 644 model-independent information. 646 Within an engine using a TMSM-based security model, outgoing SNMP 647 messages are passed unencrypted from the message dispatcher to the 648 transport mapping, and incoming messages are passed unencrypted from 649 the transport mapping to the message dispatcher. 651 The security parameters include a model-independent identifier of the 652 security "principal", the security model used to perform the 653 authentication, and which SNMP-specific security services were 654 (should be) applied to the message (authentication and/or privacy). 656 In the RFC3411 architecture, which reflects the USM security model 657 design, the messaging model must unpack SNMP-specific security 658 parameters from an incoming message before calling a specific 659 security model to authenticate and decrypt an incoming message, 660 perform integrity checking, and translate model-specific security 661 parameters into model-independent parameters. 663 In the TMSM approach, the security-model specific parameters are not 664 carried in the SNMP message. The parameters are provided by SNMP 665 applications for outgoing messages, and the parameters for incoming 666 messages are extracted from the transport layer by the security- 667 model-specific transport mapping before the message is passed to the 668 message processing subsystem. 670 For outgoing messages, it is necessary to have an SMSP because it is 671 the SMSP that actually creates the message from its component parts. 672 Whether there are any security services provided by the SMSP for an 673 outgoing message is model-dependent. 675 For incoming messages, there might be security functionality that can 676 only be handled after the message version is known. The message 677 version is determined by the Message Processing model and passed to 678 the SMSP via the processIncoming() ASI. 680 The RFC3411 architecture has no ASI parameters for passing security 681 information between the transport mapping and the dispatcher, and 682 between the dispatcher and the message processing model. If there is 683 a need to have an SMSP called from the message processing model to, 684 for example, verify that msgFlags and the transport security are 685 consistent, then it will be necessary to pass the model-dependent 686 security parameters from the TMSP through to the SMSP. 688 This document describes a cache, into which the TMSP puts information 689 about the security applied to an incoming message, and an SMSP 690 extracts that information from the cache. Given that there may be 691 multiple TM-security caches, a tmSessionReference is passed as an 692 extra parameter in the ASIs between the transport mapping and the 693 messaging security model, so the SMSP knows which cache of 694 information to consult. 696 This approach does create dependencies between a model-specific TMSP 697 and a corresponding specific SMSP. This approach of passing a model- 698 independent reference is consistent with the securityStateReference 699 cache already being passed around in the RFC3411 ASIs. 701 2.3. Session Requirements 703 Throughout this document, the term session is used. Some underlying 704 secure transports will have a notion of session. Some underlying 705 secure transports might enable the use of channels or other session- 706 like thing. In this document the term session refers to an 707 association between two SNMP engines that permits the secure 708 transmission of one or more SNMP messages within the lifetime of the 709 session. How the session is actually established, opened, closed, or 710 maintained is specific to a particular security model. 712 Sessions are not part of the SNMP architecture described in 713 [RFC3411], but are considered desirable because the cost of 714 authentication can be amortized over potentially many transactions. 716 It is important to note that the architecture described in [RFC3411] 717 does not include a session selector in the Abstract Service 718 Interfaces, and neither is that done for this architectural 719 extension, so an SNMP application cannot select the session except by 720 passing a unique combination of transport address, securityName, 721 securityModel, and securityLevel. 723 All TMSM-based security models should discuss the impact of sessions 724 on SNMP usage, including how to establish/open a TMSM session (i.e., 725 how it maps to the concepts of session-like things of the underlying 726 protocol), how to behave when a TMSM session cannot be established, 727 how to close a TMSM session (and the underlying protocol equivalent) 728 properly, how to behave when a TMSM session is closed improperly, the 729 session security properties, session establishment overhead, and 730 session maintenance overhead. 732 To reduce redundancy, this document will discuss aspects that are 733 expected to be common to all TMSM-based security model sessions. 735 2.3.1. Session Establishment Requirements 737 SNMP applications must provide the transport address, securityName, 738 securityModel, and securityLevel to be used for a session. 740 SNMP Applications typically have no knowledge of whether the session 741 that will be used to carry commands was initially established as a 742 notification session, or a request-response session, and SHOULD NOT 743 make any assumptions based on knowing the direction of the session. 744 If an administrator or security model designer wants to differentiate 745 a session established for different purposes, such as a notification 746 session versus a request-response session, the application can use 747 different securityNames or transport addresses (e.g., port 161 vs. 748 port 162) for different purposes. 750 An SNMP engine containing an application that initiates 751 communication, e.g., a Command Generator or Notification Originator, 752 MUST be able to attempt to establish a session for delivery if a 753 session does not yet exist. If a session cannot be established then 754 the message is discarded. 756 Sessions are usually established by the transport mapping security 757 processor when no appropriate session is found for an outgoing 758 message, but sessions may be established in advance to support 759 features such as notifications and call-home. How sessions are 760 established in advance is beyond the scope of this document. 762 Sessions are initiated by notification originators when there is no 763 currently established connection that can be used to send the 764 notification. For a client-server security protocol, this may 765 require provisioning authentication credentials on the agent, either 766 statically or dynamically, so the client/agent can successfully 767 authenticate to a notification receiver. 769 A TMSM-based security model must be able to determine whether a 770 session does or does not exist, and must be able to determine which 771 session has the appropriate security characteristics (transport 772 address, securityName, securityModel, and securityLevel) for an 773 outgoing message. 775 A TMSM security model implementation MAY reuse an already established 776 session with the appropriate transport address, securityName, 777 securityModel, and securityLevel characteristics for delivery of a 778 message originated by a different type of application than originally 779 caused the session to be created. For example, an implementation 780 that has an existing session originally established to receive a 781 request may use that session to send an outgoing notification, and 782 may use a session that was originally established to send a 783 notification to send a request. Responses are expected to be 784 returned using the same session that carried the corresponding 785 request message. Reuse is not required for conformance. 787 If a session can be reused for a different type of message, but a 788 receiver is not prepared to accept different message types over the 789 same session, then the message MAY be dropped by the manager. 791 2.3.2. Session Maintenance Requirements 793 A TMSM-based security model can tear down sessions as needed. It may 794 be necessary for some implementations to tear down sessions as the 795 result of resource constraints, for example. 797 The decision to tear down a session is implementation-dependent. 798 While it is possible for an implementation to automatically tear down 799 each session once an operation has completed, this is not recommended 800 for anticipated performance reasons. How an implementation 801 determines that an operation has completed, including all potential 802 error paths, is implementation-dependent. 804 Implementations should be careful to not tear down a session between 805 the time a request is received and the time the response is sent. 806 The elements of procedure for TMSM-based security models should be 807 sure to describe the expected behavior when no session exists for a 808 response. 810 The elements of procedure may discuss when cached information can be 811 discarded, and the timing of cache cleanup may have security 812 implications, but cache memory management is an implementation issue. 814 If a security model defines MIB module objects to maintain session 815 state information, then the security model MUST describe what happens 816 to the objects when a related session is torn down, since this will 817 impact interoperability of the MIB module. 819 2.3.3. Message security versus session security 821 A TMSM session is associated with state information that is 822 maintained for its lifetime. This state information allows for the 823 application of various security services to TMSM-based security 824 models. Cryptographic keys established at the beginning of the 825 session SHOULD be used to provide authentication, integrity checking, 826 and encryption services for data that is communicated during the 827 session. The cryptographic protocols used to establish keys for a 828 TMSM-based security model session SHOULD ensure that fresh new 829 session keys are generated for each session. If each session uses 830 new session keys, then messages cannot be replayed from one session 831 to another. In addition sequence information MAY be maintained in 832 the session which can be used to prevent the replay and reordering of 833 messages within a session. 835 A TMSM session will typically have a single transport address, 836 securityName and securityLevel associated with it. If an exchange 837 between communicating engines would require a different securityLevel 838 or would be on behalf of a different securityName, then another 839 session would be needed. An immediate consequence of this is that 840 implementations should be able to maintain some reasonable number of 841 concurrent sessions. 843 For TMSM models, securityName is typically specified during session 844 setup, and associated with the session identifier. 846 SNMPv3 was designed to support multiple levels of security, 847 selectable on a per-message basis by an SNMP application, because 848 there is not much value in using encryption for a Commander Generator 849 to poll for non-sensitive performance data on thousands of interfaces 850 every ten minutes; the encryption adds significant overhead to 851 processing of the messages. 853 Some TMSM-based security models MAY support only specific 854 authentication and encryption services, such as requiring all 855 messages to be carried using both authentication and encryption, 856 regardless of the security level requested by an SNMP application. 858 Some security models may use an underlying transport that provides a 859 per-message requested level of authentication and encryption 860 services. For example, if a session is created as 'authPriv', then 861 keys for encryption could still be negotiated once at the beginning 862 of the session. But if a message is presented to the session with a 863 security level of authNoPriv, then that message could simply be 864 authenticated and not encrypted within the same transport session. 865 Whether this is possible depends on the security model and the secure 866 transport used. 868 If the underlying transport layer security was configurable on a per- 869 message basis, a TMSM-based security model could have a security- 870 model-specific MIB module with configurable maxSecurityLevel and a 871 minSecurityLevel objects to identify the range of possible levels. A 872 session's maxSecurityLevel would identify the maximum security it 873 could provide, and a session created with a minSecurityLevel of 874 authPriv would reject an attempt to send an authNoPriv message. The 875 elements of procedure of the security model would need to describe 876 the procedures to enable this determination. 878 For security models that do not support variable security services in 879 one session, multiple sessions could be established with different 880 security levels, and for every packet the SNMP engine could select 881 the appropriate session based on the requested securityLevel. Some 882 SNMP entities are resource-constrained. Adding sessions increases 883 the need for resources, but so does encrypting unnecessarily. 884 Designers of security models should consider the trade offs for 885 resource-constrained devices. 887 3. Scenario Diagrams for TMSM 889 RFC3411 section 4.6 provides scenario diagrams to illustrate how an 890 outgoing message is created, and how an incoming message is 891 processed. Both diagrams are incomplete, however. In section 4.6.1, 892 the diagram doesn't show the ASI for sending an SNMP request to the 893 network or receiving an SNMP response message from the network. In 894 section 4.6.2, the diagram doesn't illustrate the interfaces required 895 to receive an SNMP message from the network, or to send an SNMP 896 message to the network. 898 3.1. Command Generator or Notification Originator 900 This diagram from RFC3411 4.6.1 shows how a Command Generator or 901 Notification Originator application [RFC3413] requests that a PDU be 902 sent, and how the response is returned (asynchronously) to that 903 application. 905 Command Dispatcher Message Security 906 Generator | Processing Model 907 | | Model | 908 | sendPdu | | | 909 |------------------->| | | 910 | | prepareOutgoingMessage | | 911 : |----------------------->| | 912 : | | generateRequestMsg | 913 : | |-------------------->| 914 : | | | 915 : | |<--------------------| 916 : | | | 917 : |<-----------------------| | 918 : | | | 919 : |------------------+ | | 920 : | Send SNMP | | | 921 : | Request Message | | | 922 : | to Network | | | 923 : | v | | 924 : : : : : 925 : : : : : 926 : : : : : 927 : | | | | 928 : | Receive SNMP | | | 929 : | Response Message | | | 930 : | from Network | | | 931 : |<-----------------+ | | 932 : | | | 933 : | prepareDataElements | | 934 : |----------------------->| | 935 : | | processIncomingMsg | 936 : | |-------------------->| 937 : | | | 938 : | |<--------------------| 939 : | | | 940 : |<-----------------------| | 941 | processResponsePdu | | | 942 |<-------------------| | | 943 | | | | 945 3.2. Command Responder 947 This diagram shows how a Command Responder or Notification Receiver 948 application registers for handling a pduType, how a PDU is dispatched 949 to the application after an SNMP message is received, and how the 950 Response is (asynchronously) send back to the network. 952 Command Dispatcher Message Security 953 Responder | Processing Model 954 | | Model | 955 | | | | 956 | registerContextEngineID | | | 957 |------------------------>| | | 958 |<------------------------| | | | 959 | | Receive SNMP | | | 960 : | Message | | | 961 : | from Network | | | 962 : |<-------------+ | | 963 : | | | 964 : |prepareDataElements | | 965 : |------------------->| | 966 : | | processIncomingMsg | 967 : | |------------------->| 968 : | | | 969 : | |<-------------------| 970 : | | | 971 : |<-------------------| | 972 | processPdu | | | 973 |<------------------------| | | 974 | | | | 975 : : : : 976 : : : : 977 | returnResponsePdu | | | 978 |------------------------>| | | 979 : | prepareResponseMsg | | 980 : |------------------->| | 981 : | |generateResponseMsg | 982 : | |------------------->| 983 : | | | 984 : | |<-------------------| 985 : | | | 986 : |<-------------------| | 987 : | | | 988 : |--------------+ | | 989 : | Send SNMP | | | 990 : | Message | | | 991 : | to Network | | | 992 : | v | | 994 4. Message Formats 996 The syntax of an SNMP message using this Security Model adheres to 997 the message format defined in the version-specific Message Processing 998 Model document (for example [RFC3412]). At the time of this writing, 999 there are three defined message formats - SNMPv1, SNMPv2c, and 1000 SNMPv3. SNMPv1 and SNMPv2c have been declared Historic, so this memo 1001 only deals with SNMPv3 messages. 1003 The processing is compatible with the RFC 3412 primitives, 1004 generateRequestMsg() and processIncomingMsg(), that show the data 1005 flow between the Message Processor and the SMSP. 1007 4.1. SNMPv3 Message Fields 1009 The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416]. 1011 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 1013 SNMPv3Message ::= SEQUENCE { 1014 -- identify the layout of the SNMPv3Message 1015 -- this element is in same position as in SNMPv1 1016 -- and SNMPv2c, allowing recognition 1017 -- the value 3 is used for snmpv3 1018 msgVersion INTEGER ( 0 .. 2147483647 ), 1019 -- administrative parameters 1020 msgGlobalData HeaderData, 1021 -- security model-specific parameters 1022 -- format defined by Security Model 1023 msgSecurityParameters OCTET STRING, 1024 msgData ScopedPduData 1025 } 1027 HeaderData ::= SEQUENCE { 1028 msgID INTEGER (0..2147483647), 1029 msgMaxSize INTEGER (484..2147483647), 1031 msgFlags OCTET STRING (SIZE(1)), 1032 -- .... ...1 authFlag 1033 -- .... ..1. privFlag 1034 -- .... .1.. reportableFlag 1035 -- Please observe: 1036 -- .... ..00 is OK, means noAuthNoPriv 1037 -- .... ..01 is OK, means authNoPriv 1038 -- .... ..10 reserved, MUST NOT be used. 1039 -- .... ..11 is OK, means authPriv 1041 msgSecurityModel INTEGER (1..2147483647) 1042 } 1044 ScopedPduData ::= CHOICE { 1045 plaintext ScopedPDU, 1046 encryptedPDU OCTET STRING -- encrypted scopedPDU value 1047 } 1049 ScopedPDU ::= SEQUENCE { 1050 contextEngineID OCTET STRING, 1051 contextName OCTET STRING, 1052 data ANY -- e.g., PDUs as defined in [RFC3416] 1053 } 1054 END 1056 The following describes how any TMSM model SHOULD treat certain 1057 fields in the message: 1059 4.1.1. msgGlobalData 1061 msgGlobalData is opaque to a TMSM security model. The values are set 1062 by the Message Processing model (e.g., SNMPv3 Message Processing), 1063 and SHOULD NOT be modified by a TMSM security model. 1065 The msgSecurityModel field should be set by the Message Processing 1066 model to a value from the SnmpSecurityModel enumeration [RFC3411] to 1067 identify the specific TMSM model. Each standards-track TMSM model 1068 should have an enumeration assigned by IANA. Each enterprise- 1069 specific security model should have an enumeration assigned following 1070 instructions in the description of the SnmpSecurityModel TEXTUAL- 1071 CONVENTION from RFC3411. 1073 The msgFlags have the same values for a TMSM model as for the USM 1074 model. 1076 4.1.1.1. securityLevel and msgFlags 1078 For an outgoing message, msgFlags is the requested security for the 1079 message; if a TMSM cannot provide the requested securityLevel, the 1080 model MUST describe a standard behavior that is followed for that 1081 situation. If the TMSM cannot provide at least the requested level 1082 of security, the TMSM MUST discard the request and SHOULD notify the 1083 message processing model that the request failed. 1085 For an outgoing message, if the TMSM is able to provide stronger than 1086 requested security, that may be acceptable. The transport layer 1087 protocol would need to indicate to the receiver what security has 1088 been applied to the actual message. To avoid the need to mess with 1089 the ASN.1 encoding, the SNMPv3 message carries the requested 1090 msgFlags, not the actual securityLevel applied to the message. If a 1091 message format other than SNMPv3 is used, then the new message may 1092 carry the more accurate securityLevel in the SNMP message. 1094 For an incoming message, the receiving TMSM knows what must be done 1095 to process the message based on the transport layer mechanisms. If 1096 the underlying transport security mechanisms for the receiver cannot 1097 provide the matching securityLevel, then the message should follow 1098 the standard behaviors for the transport security mechanism, or be 1099 discarded silently. 1101 Part of the responsibility of the TMSM is to ensure that the actual 1102 security provided by the underlying transport layer security 1103 mechanisms is configured to meet or exceed the securityLevel required 1104 by the msgFlags in the SNMP message. When the SMSP processes the 1105 incoming message, it should compare the msgFlags field to the 1106 securityLevel actually provided for the message by the transport 1107 layer security. If they differ, the SMSP should determine whether 1108 the changed securityLevel is acceptable. If not, it should discard 1109 the message. Depending on the model, the SMSP may issue a reportPDU 1110 with a model-specific counter. 1112 4.1.2. msgSecurityParameters 1114 The field msgSecurityParameters carries model-dependent security 1115 information between engines. When a security model does not utilize 1116 this field, its value MUST be the BER serialization of a zero-length 1117 OCTET STRING, to prevent its being used in a manner that could be 1118 damaging, such as for carrying a virus or worm. 1120 RFC3412 defines two primitives, generateRequestMsg() and 1121 processIncomingMsg() which require the specification of an 1122 authoritative SNMP entity. The meaning of authoritative is model 1123 dependent. 1125 5. Cached Information and References 1127 he RFC3411 architecture uses caches to store dynamic model-specific 1128 information, and uses references in the ASIs to indicate in a model- 1129 independent manner which cached information must flow between 1130 subsystems. For most TMSM models, there are two levels of state that 1131 need to be maintained: the session state, and the message security 1132 state. 1134 5.1. tmSessionReference Cached Session Data 1136 The tmSessionReference is used to pass references to the appropriate 1137 session information between the TMSP and SMSP through the ASIs. 1139 The TMSP may provide only some aspects of security, and leave some 1140 aspects to the SMSP. tmSessionReference should be used to pass any 1141 parameters, in a model- and mechanism-specific format, that will be 1142 needed to coordinate the activities of the TMSP and SMSP, plus the 1143 parameters subsequently passed in securityStateReference. 1145 The security model has the responsibility for explicitly releasing 1146 the complete tmSessionReference and possibly deleting the associated 1147 LCD information when the session is destroyed. 1149 5.2. securityStateReference Cached Security Data 1151 From RFC3411: "For each message received, the Security Model caches 1152 the state information such that a Response message can be generated 1153 using the same security information, even if the Local Configuration 1154 Datastore is altered between the time of the incoming request and the 1155 outgoing response. 1157 A Message Processing Model has the responsibility for explicitly 1158 releasing the cached data if such data is no longer needed. To 1159 enable this, an abstract securityStateReference data element is 1160 passed from the Security Model to the Message Processing Model. The 1161 cached security data may be implicitly released via the generation of 1162 a response, or explicitly released by using the stateRelease 1163 primitive, as described in RFC3411 section 4.5.1." 1165 For the TMSM approach, the TMSP may need to provide the information 1166 to be stored in the securityStateReference to the message processing 1167 model. such as the security-model-independent securityName, 1168 securityLevel, and securityModel parameters, and the transport 1169 address, and transport type. For responses, the messaging model may 1170 need to pass the parameters back to the TMSP. 1172 This document will differentiate the tmSessionReference provided by 1173 the TMSP to the SMSP, from the securityStateReference provided by the 1174 SMSP to the Dispatcher. This document does not specify an 1175 implementation strategy, only an abstract discussion of the data that 1176 must flow between subsystems. An implementation MAY use one cache 1177 and one reference to serve both functions, but an implementer must be 1178 aware of the cache-release issues to prevent the cache from being 1179 released before the transport mapping has had an opportunity to 1180 extract the information it needs. 1182 6. Abstract Service Interfaces for TMSM 1184 Abstract service interfaces have been defined by RFC 3411 to describe 1185 the conceptual data flows between the various subsystems within an 1186 SNMP entity. TMSM security models use some of these conceptual data 1187 flows when communicating between subsystems, such as the dispatcher 1188 and the Message Processing Subsystem. 1190 To simplify the elements of procedure, the release of state 1191 information is not always explicitly specified. As a general rule, 1192 if state information is available when a message gets discarded, the 1193 message-state information should also be released, and if state 1194 information is available when a session is closed, the session state 1195 information should also be released. 1197 An error indication may return an OID and value for an incremented 1198 counter and a value for securityLevel, and values for contextEngineID 1199 and contextName for the counter, and the securityStateReference if 1200 the information is available at the point where the error is 1201 detected. 1203 6.1. Generating an Outgoing SNMP Message 1205 This section describes the procedure followed by an RFC3411- 1206 compatible system whenever it generates a message containing a 1207 management operation (such as a request, a response, a notification, 1208 or a report) on behalf of a user. 1210 statusInformation = -- success or errorIndication 1211 prepareOutgoingMessage( 1212 IN transportDomain -- transport domain to be used 1213 IN transportAddress -- transport address to be used 1214 IN messageProcessingModel -- typically, SNMP version 1215 IN securityModel -- Security Model to use 1216 IN securityName -- on behalf of this principal 1217 IN securityLevel -- Level of Security requested 1218 IN contextEngineID -- data from/at this entity 1219 IN contextName -- data from/in this context 1220 IN pduVersion -- the version of the PDU 1221 IN PDU -- SNMP Protocol Data Unit 1222 IN expectResponse -- TRUE or FALSE 1223 IN sendPduHandle -- the handle for matching 1224 incoming responses 1225 OUT destTransportDomain -- destination transport domain 1226 OUT destTransportAddress -- destination transport address 1227 OUT outgoingMessage -- the message to send 1228 OUT outgoingMessageLength -- its length 1229 OUT tmSessionReference 1230 ) 1232 Note that tmSessionReference has been added to this ASI. 1234 The IN parameters of the prepareOutgoingMessage() ASI are used to 1235 pass information from the dispatcher (for the application subsystem) 1236 to the message processing subsystem. 1238 The abstract service primitive from a Message Processing Model to a 1239 Security Model to generate the components of a Request message is 1240 generateRequestMsg(). 1242 The abstract service primitive from a Message Processing Model to a 1243 Security Model to generate the components of a Response message is 1244 generateResponseMsg(). 1246 Upon completion of the SMSP processing, the Security model returns 1247 statusInformation. If the process was successful, the completed 1248 message is returned. If the process was not successful, then an 1249 errorIndication is returned. 1251 The OUT parameters of the prepareOutgoingMessage() ASI are used to 1252 pass information from the message processing model to the dispatcher 1253 and on to the transport mapping: 1255 6.2. TMSP for an Outgoing Message 1257 The sendMessage ASI is used to pass a message from the Dispatcher to 1258 the appropriate transport mapping for sending. 1260 statusInformation = 1261 sendMessage( 1262 IN destTransportDomain -- transport domain to be used 1263 IN destTransportAddress -- transport address to be used 1264 IN outgoingMessage -- the message to send 1265 IN outgoingMessageLength -- its length 1266 IN tmSessionReference 1267 ) 1269 The Transport Mapping Security Model provides the following 1270 primitives to pass data back and forth between the TMSM and specific 1271 TMSM-based security models, which provide the interface to the 1272 underlying secure transport service. Each TMSM-based security model 1273 should define the security-model-specific elements of procedure for 1274 the openSession() and closeSession() interfaces. 1276 statusInformation = 1277 openSession( 1278 IN transportDomain -- transport domain to be used 1279 IN transportAddress -- transport address to be used 1280 IN tmSessionReference 1281 ) 1283 statusInformation = 1284 closeSession( 1285 IN tmSessionReference 1286 ) 1288 6.3. Processing an Incoming SNMP Message 1290 6.3.1. TMSP for an Incoming Message 1292 If one does not exist, the TMSP will need to create an entry in a 1293 Local Configuration Datastore referenced by tmSessionReference. This 1294 information will include transportDomain, transportAddress, the 1295 securityModel, the securityLevel, and the securityName, plus any 1296 model or mechanism-specific details. How this information is 1297 determined is model-specific. 1299 The recvMessage ASI is used to pass a message from the transport 1300 mapping to the Dispatcher. 1302 statusInformation = 1303 recvMessage( 1304 IN destTransportDomain -- transport domain to be used 1305 IN destTransportAddress -- transport address to be used 1306 IN incomingMessage -- the message received 1307 IN incomingMessageLength -- its length 1308 IN tmSessionReference 1309 ) 1311 6.3.2. Prepare Data Elements from Incoming Messages 1313 The abstract service primitive from the Dispatcher to a Message 1314 Processing Model for a received message is: 1316 result = -- SUCCESS or errorIndication 1317 prepareDataElements( 1318 IN transportDomain -- origin transport domain 1319 IN transportAddress -- origin transport address 1320 IN wholeMsg -- as received from the network 1321 IN wholeMsgLength -- as received from the network 1322 IN tmSessionReference -- from the transport mapping 1323 OUT messageProcessingModel -- typically, SNMP version 1324 OUT securityModel -- Security Model to use 1325 OUT securityName -- on behalf of this principal 1326 OUT securityLevel -- Level of Security requested 1327 OUT contextEngineID -- data from/at this entity 1328 OUT contextName -- data from/in this context 1329 OUT pduVersion -- the version of the PDU 1330 OUT PDU -- SNMP Protocol Data Unit 1331 OUT pduType -- SNMP PDU type 1332 OUT sendPduHandle -- handle for matched request 1333 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1334 OUT statusInformation -- success or errorIndication 1335 -- error counter OID/value if error 1336 OUT stateReference -- reference to state information 1337 -- to be used for possible Response 1338 ) 1340 Note that tmSessionReference has been added to this ASI. 1342 6.3.3. MPSP for an Incoming Message 1344 This section describes the procedure followed by the SMSP whenever it 1345 receives an incoming message containing a management operation on 1346 behalf of a user from a Message Processing model. 1348 The Message Processing Model extracts some information from the 1349 wholeMsg. The abstract service primitive from a Message Processing 1350 Model to the Security Subsystem for a received message is:: 1352 statusInformation = -- errorIndication or success 1353 -- error counter OID/value if error 1354 processIncomingMsg( 1355 IN messageProcessingModel -- typically, SNMP version 1356 IN maxMessageSize -- of the sending SNMP entity 1357 IN securityParameters -- for the received message 1358 IN securityModel -- for the received message 1359 IN securityLevel -- Level of Security 1360 IN wholeMsg -- as received on the wire 1361 IN wholeMsgLength -- length as received on the wire 1362 IN tmSessionReference -- from the transport mapping 1363 OUT securityEngineID -- authoritative SNMP entity 1364 OUT securityName -- identification of the principal 1365 OUT scopedPDU, -- message (plaintext) payload 1366 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1367 OUT securityStateReference -- reference to security state 1368 ) -- information, needed for response 1370 1) The securityEngineID is set to a value in a model-specific manner. 1371 If the securityEngineID is not utilized by the specific model, then 1372 it should be set to the local snmpEngineID, to satisfy the SNMPv3 1373 message processing model in RFC 3412 section 7.2 13a). 1375 2) Extract the value of securityName from the Local Configuration 1376 Datastore entry referenced by tmSessionReference. 1378 3) The scopedPDU component is extracted from the wholeMsg. 1380 4) The maxSizeResponseScopedPDU is calculated. This is the maximum 1381 size allowed for a scopedPDU for a possible Response message. 1383 5)The security data is cached as cachedSecurityData, so that a 1384 possible response to this message can and will use the same security 1385 parameters. Then securityStateReference is set for subsequent 1386 reference to this cached data. 1388 4) The statusInformation is set to success and a return is made to 1389 the calling module passing back the OUT parameters as specified in 1390 the processIncomingMsg primitive. 1392 7. The TMSM MIB Module 1394 This memo defines a portion of the Management Information Base (MIB) 1395 for statistics in the Transport Mapping Security Model extension. 1397 7.1. Structure of the MIB Module 1399 Objects in this MIB module are arranged into subtrees. Each subtree 1400 is organized as a set of related objects. The overall structure and 1401 assignment of objects to their subtrees, and the intended purpose of 1402 each subtree, is shown below. 1404 7.1.1. The tmsmStats Subtree 1406 This subtree contains security-model-independent counters which are 1407 applicable to all security models based on the .Transport Mapping 1408 Security Model extension. This subtree provides information for 1409 identifying fault conditions and performance degradation. 1411 7.2. Relationship to Other MIB Modules 1413 Some management objects defined in other MIB modules are applicable 1414 to an entity implementing this MIB. In particular, it is assumed 1415 that an entity implementing the TMSM-MIB module will also implement 1416 the SNMPv2-MIB [RFC3418]. 1418 This MIB module is expected to be used with the MIB modules defined 1419 for managing specific security models that are based on the TMSM 1420 extension. This MIB module is designed to be security-model 1421 independent, and contains objects useful for managing common aspects 1422 of any TMSM-based security model. Specific security models may 1423 define a MIB module to contain security-model-dependent information. 1425 7.2.1. Textual Conventions 1427 Generic and Common Textual Conventions used in this document can be 1428 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1430 7.2.2. MIB Modules Required for IMPORTS 1432 The. following MIB module imports items from [RFC2578], [RFC2579], 1433 [RFC2580], [RFC3411], and [RFC3419] 1435 7.3. Definitions 1437 TMSM-MIB DEFINITIONS ::= BEGIN 1438 IMPORTS 1439 MODULE-IDENTITY, OBJECT-TYPE, 1440 mib-2, Integer32, Unsigned32, Gauge32 1441 FROM SNMPv2-SMI 1442 TestAndIncr, StorageType, RowStatus 1443 FROM SNMPv2-TC 1444 MODULE-COMPLIANCE, OBJECT-GROUP 1445 FROM SNMPv2-CONF 1446 SnmpSecurityModel, 1447 SnmpAdminString, SnmpSecurityLevel, SnmpEngineID 1448 FROM SNMP-FRAMEWORK-MIB 1449 TransportAddress, TransportAddressType 1450 FROM TRANSPORT-ADDRESS-MIB 1451 ; 1453 tmsmMIB MODULE-IDENTITY 1454 LAST-UPDATED "200604200000Z" 1455 ORGANIZATION "ISMS Working Group" 1456 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1457 Subscribe: isms-request@lists.ietf.org 1459 Chairs: 1460 Juergen Quittek 1461 NEC Europe Ltd. 1462 Network Laboratories 1463 Kurfuersten-Anlage 36 1464 69115 Heidelberg 1465 Germany 1466 +49 6221 90511-15 1467 quittek@netlab.nec.de 1469 Juergen Schoenwaelder 1470 International University Bremen 1471 Campus Ring 1 1472 28725 Bremen 1473 Germany 1474 +49 421 200-3587 1475 j.schoenwaelder@iu-bremen.de 1477 Editor: 1478 David Harrington 1479 FutureWei Technologies 1480 1700 Alma Drive, Suite 100 1481 Plano, Texas 75075 1482 USA 1483 +1 603-436-8634 1484 dharrington@huawei.com 1485 " 1487 DESCRIPTION "The Transport Mapping Security Model 1488 MIB Module 1490 Copyright (C) The Internet Society (2006). This 1491 version of this MIB module is part of RFC XXXX; 1492 see the RFC itself for full legal notices. 1493 -- NOTE to RFC editor: replace XXXX with actual RFC number 1494 -- for this document and remove this note 1495 " 1497 REVISION "200604200000Z" -- 20 April 2006 1498 DESCRIPTION "The initial version, published in RFC XXXX. 1499 -- NOTE to RFC editor: replace XXXX with actual RFC number 1500 -- for this document and remove this note 1501 " 1503 ::= { mib-2 xxxx } 1504 -- RFC Ed.: replace xxxx with IANA-assigned number and 1505 -- remove this note 1507 -- ---------------------------------------------------------- -- 1508 -- subtrees in the TMSM-MIB 1509 -- ---------------------------------------------------------- -- 1511 tmsmNotifications OBJECT IDENTIFIER ::= { tmsmMIB 0 } 1512 tmsmObjects OBJECT IDENTIFIER ::= { tmsmMIB 1 } 1513 tmsmConformance OBJECT IDENTIFIER ::= { tmsmMIB 2 } 1515 -- ------------------------------------------------------------- 1516 -- Objects 1517 -- ------------------------------------------------------------- 1519 -- Textual Conventions 1521 -- Notifications for the Transport Model Security Model extension 1523 -- Statistics for the Transport Model Security Model extension 1525 tmsmStats OBJECT IDENTIFIER ::= { tmsmObjects 1 } 1527 tmsmSessionOpenErrors OBJECT-TYPE 1528 SYNTAX Counter32 1529 MAX-ACCESS read-only 1530 STATUS current 1531 DESCRIPTION "The number of times an openSession() request 1532 failed to open a Session. 1533 " 1535 ::= { tmsmStats 1 } 1537 tmsmSessionNoAvailableSessions OBJECT-TYPE 1538 SYNTAX Counter32 1539 MAX-ACCESS read-only 1540 STATUS current 1541 DESCRIPTION "The number of times a Response message 1542 was dropped because the corresponding 1543 session was no longer available. 1544 " 1545 ::= { tmsmStats 2 } 1547 -- The tmsmSession Group 1549 tmsmSession OBJECT IDENTIFIER ::= { tmsmObjects 2 } 1551 tmsmSessionCurrent OBJECT-TYPE 1552 SYNTAX Gauge32 1553 MAX-ACCESS read-only 1554 STATUS current 1555 DESCRIPTION "The current number of open sessions. 1556 " 1557 ::= { tmsmSession 1 } 1559 tmsmSessionMaxSupported OBJECT-TYPE 1560 SYNTAX Unsigned32 1561 MAX-ACCESS read-only 1562 STATUS current 1563 DESCRIPTION "The maximum number of open sessions supported. 1564 The value zero indicates the maximum is dynamic. 1565 " 1566 ::= { tmsmSession 2 } 1568 tmsmSessionOpenErrors OBJECT-TYPE 1569 SYNTAX Counter32 1570 MAX-ACCESS read-only 1571 STATUS current 1572 DESCRIPTION "The number of times an openSession() request 1573 failed to open a Session. 1574 " 1575 ::= { tmsmSession 3 } 1577 tmsmSessionSecurityLevelNotAvailableErrors OBJECT-TYPE 1578 SYNTAX Counter32 1579 MAX-ACCESS read-only 1580 STATUS current 1581 DESCRIPTION "The number of times an outgoing message was 1582 discarded because a requested securityLevel could not 1583 provided. 1584 " 1585 ::= { tmsmSession 4 } 1587 -- ------------------------------------------------------------- 1588 -- tmsmMIB - Conformance Information 1589 -- ------------------------------------------------------------- 1591 tmsmGroups OBJECT IDENTIFIER ::= { tmsmConformance 1 } 1593 tmsmCompliances OBJECT IDENTIFIER ::= { tmsmConformance 2 } 1595 -- ------------------------------------------------------------- 1596 -- Units of conformance 1597 -- ------------------------------------------------------------- 1598 tmsmGroup OBJECT-GROUP 1599 OBJECTS { 1600 tmsmSessionOpenErrors, 1601 tmsmSessionSecurityLevelNotAvailableErrors, 1602 tmsmSessionCurrent, 1603 tmsmSessionMaxSupported, 1604 } 1605 STATUS current 1606 DESCRIPTION "A collection of objects for maintaining session 1607 information of an SNMP engine which implements the 1608 TMSM architectural extension. 1609 " 1611 ::= { tmsmGroups 2 } 1613 -- ------------------------------------------------------------- 1614 -- Compliance statements 1615 -- ------------------------------------------------------------- 1617 tmsmCompliance MODULE-COMPLIANCE 1618 STATUS current 1619 DESCRIPTION 1620 "The compliance statement for SNMP engines that support the 1621 TMSM-MIB" 1622 MODULE 1623 MANDATORY-GROUPS { tmsmGroup } 1624 ::= { tmsmCompliances 1 } 1626 END 1628 8. Security Considerations 1630 This document describes an architectural approach and multiple 1631 proposed configurations that would permit SNMP to utilize transport 1632 layer security services. Each section containing a proposal should 1633 discuss the security considerations of that approach. 1635 It is considered desirable by some industry segments that SNMP 1636 security models should utilize transport layer security that 1637 addresses perfect forward secrecy at least for encryption keys. 1638 Perfect forward secrecy guarantees that compromise of long term 1639 secret keys does not result in disclosure of past session keys. 1641 There are no management objects defined in this MIB module that have 1642 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1643 MIB module is implemented correctly, then there is no risk that an 1644 intruder can alter or create any management objects of this MIB 1645 module via direct SNMP SET operations. 1647 Some of the readable objects in this MIB module (i.e., objects with a 1648 MAX-ACCESS other than not-accessible) may be considered sensitive or 1649 vulnerable in some network environments. It is thus important to 1650 control even GET and/or NOTIFY access to these objects and possibly 1651 to even encrypt the values of these objects when sending them over 1652 the network via SNMP. These are the tables and objects and their 1653 sensitivity/vulnerability: 1654 o [todo] list the tables and objects and state why they are 1655 sensitive. 1657 SNMP versions prior to SNMPv3 did not include adequate security. 1658 Even if the network itself is secure (for example by using IPSec), 1659 even then, there is no control as to who on the secure network is 1660 allowed to access and GET/SET (read/change/create/delete) the objects 1661 in this MIB module. 1663 It is RECOMMENDED that implementers consider the security features as 1664 provided by the SNMPv3 framework (see [RFC3410], section 8), 1665 including full support for the SNMPv3 cryptographic mechanisms (for 1666 authentication and privacy). 1668 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1669 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1670 enable cryptographic security. It is then a customer/operator 1671 responsibility to ensure that the SNMP entity giving access to an 1672 instance of this MIB module is properly configured to give access to 1673 the objects only to those principals (users) that have legitimate 1674 rights to indeed GET or SET (change/create/delete) them. 1676 9. IANA Considerations 1678 The MIB module in this document uses the following IANA-assigned 1679 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1681 Descriptor OBJECT IDENTIFIER value 1682 ---------- ----------------------- 1684 tmsmMIB { mib-2 XXXX } 1686 Editor's Note (to be removed prior to publication): the IANA is 1687 requested to assign a value for "XXXX" under the 'mib-2' subtree 1688 and to record the assignment in the SMI Numbers registry. When 1689 the assignment has been made, the RFC Editor is asked to replace 1690 "XXXX" (here and in the MIB module) with the assigned value and to 1691 remove this note. 1693 10. Acknowledgments 1695 The Integrated Security for SNMP WG would like to thank the following 1696 people for their contributions to the process: 1698 The authors of submitted security model proposals: Chris Elliot, Wes 1699 Hardaker, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave 1700 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1702 The members of the Protocol Evaluation Team: Uri Blumenthal, 1703 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1705 WG members who committed to and performed detailed reviews: Jeffrey 1706 Hutzelman 1708 11. References 1710 11.1. Normative References 1712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1713 Requirement Levels", BCP 14, RFC 2119, March 1997. 1715 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1716 and T. Wright, "Transport Layer Security (TLS) 1717 Extensions", RFC 4366, April 2006. 1719 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1720 Schoenwaelder, Ed., "Structure of Management Information 1721 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1723 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1724 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1725 STD 58, RFC 2579, April 1999. 1727 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1728 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1729 April 1999. 1731 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1732 "Remote Authentication Dial In User Service (RADIUS)", 1733 RFC 2865, June 2000. 1735 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1736 Architecture for Describing Simple Network Management 1737 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1738 December 2002. 1740 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1741 "Message Processing and Dispatching for the Simple Network 1742 Management Protocol (SNMP)", STD 62, RFC 3412, 1743 December 2002. 1745 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1746 (USM) for version 3 of the Simple Network Management 1747 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1749 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1750 Simple Network Management Protocol (SNMP)", STD 62, 1751 RFC 3416, December 2002. 1753 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1754 Management Protocol (SNMP)", STD 62, RFC 3417, 1755 December 2002. 1757 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1758 Simple Network Management Protocol (SNMP)", STD 62, 1759 RFC 3418, December 2002. 1761 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 1762 Transport Addresses", RFC 3419, December 2002. 1764 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1765 Protocol Architecture", RFC 4251, January 2006. 1767 11.2. Informative References 1769 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1770 Stewart, "Introduction and Applicability 1771 Statements for Internet-Standard Management 1772 Framework", RFC 3410, December 2002. 1774 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 1775 Network Management Protocol (SNMP) 1776 Applications", STD 62, RFC 3413, 1777 December 2002. 1779 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple 1780 Authentication and Security Layer (SASL)", 1781 RFC 4422, June 2006. 1783 [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the 1784 NETCONF Configuration Protocol over Secure 1785 Shell (SSH)", draft-ietf-netconf-ssh-06 (work 1786 in progress), March 2006. 1788 Appendix A. Parameter Table 1790 Following is a CSV formatted matrix useful for tracking data flows 1791 into and out of the dispatcher, message, and security subsystems. 1792 Import this into your favorite spreadsheet or other CSV compatible 1793 application. You will need to remove lines feeds from the second and 1794 third lines, which needed to be wrapped to fit into RFC limits. 1796 A.1. ParameterList.csv 1798 ,Dispatcher,,,,Messaging,,,Security,, 1800 ,sendPdu,returnResponse,processPdu,processResponse 1801 ,prepareOutgoingMessage,prepareResponseMessage,prepareDataElements 1802 ,generateRequest,processIncoming,generateResponse 1804 transportDomain,In,,,,In,,In,,, 1806 transportAddress,In,,,,In,,In,,, 1808 destTransportDomain,,,,,Out,Out,,,, 1810 destTransportAddress,,,,,Out,Out,,,, 1812 messageProcessingModel,In,In,In,In,In,In,Out,In,In,In 1814 securityModel,In,In,In,In,In,In,Out,In,In,In 1816 securityName,In,In,In,In,In,In,Out,In,Out,In 1818 securityLevel,In,In,In,In,In,In,Out,In,In,In 1819 contextEngineID,In,In,In,In,In,In,Out,,, 1821 contextName,In,In,In,In,In,In,Out,,, 1823 expectResponse,In,,,,In,,,,, 1825 PDU,In,In,In,In,In,In,Out,,, 1827 pduVersion,In,In,In,In,In,In,Out,,, 1829 statusInfo,Out,In,,In,,In,Out,Out,Out,Out 1831 errorIndication,Out,Out,,,,,Out,,, 1833 sendPduHandle,Out,,,In,In,,Out,,, 1835 maxSizeResponsePDU,,In,In,,,In,Out,,Out, 1837 stateReference,,In,In,,,In,Out,,, 1839 wholeMessage,,,,,Out,Out,,Out,In,Out 1841 messageLength,,,,,Out,Out,,Out,In,Out 1843 maxMessageSize,,,,,,,,In,In,In 1845 globalData,,,,,,,,In,,In 1847 securityEngineID,,,,,,,,In,Out,In 1849 scopedPDU,,,,,,,,In,Out,In 1851 securityParameters,,,,,,,,Out,,Out 1853 securityStateReference,,,,,,,,,Out,In 1855 pduType,,,,,,,Out,,, 1857 tmSessionReference,,,,,,Out,In,,In, 1859 Appendix B. Why tmSessionReference? 1861 This appendix considers why a cache-based approach was selected for 1862 passing parameters. This section may be removed from subsequent 1863 revisions of the document. 1865 There are four approaches that could be used for passing information 1866 between the TMSP and an SMSP. 1868 1. one could define an ASI to supplement the existing ASIs, or 1869 2. the TMSM could add a header to encapsulate the SNMP message, 1870 3. the TMSM could utilize fields already defined in the existing 1871 SNMPv3 message, or 1872 4. the TMSM could pass the information in an implementation-specific 1873 cache or via a MIB module. 1875 B.1. Define an Abstract Service Interface 1877 Abstract Service Interfaces (ASIs) [RFC3411] are defined by a set of 1878 primitives that specify the services provided and the abstract data 1879 elements that are to be passed when the services are invoked. 1880 Defining additional ASIs to pass the security and transport 1881 information from the transport mapping to a messaging security model 1882 has the advantage of being consistent with existing RFC3411/3412 1883 practice, and helps to ensure that any TMSM proposals pass the 1884 necessary data, and do not cause side effects by creating model- 1885 specific dependencies between itself and other models or other 1886 subsystems other than those that are clearly defined by an ASI. 1888 B.2. Using an Encapsulating Header 1890 A header could encapsulate the SNMP message to pass necessary 1891 information from the TMSP to the dispatcher and then to a messaging 1892 security model. The message header would be included in the 1893 wholeMessage ASI parameter, and would be removed by a corresponding 1894 messaging model. This would imply the (one and only) messaging 1895 dispatcher would need to be modified to determine which SNMP message 1896 version was involved, and a new message processing model would need 1897 to be developed that knew how to extract the header from the message 1898 and pass it to the SMSP. 1900 B.3. Modifying Existing Fields in an SNMP Message 1902 [RFC3412] describes the SNMPv3 message, which contains fields to pass 1903 security related parameters. The TMSM could use these fields in an 1904 SNMPv3 message, or comparable fields in other message formats to pass 1905 information between transport mapping security models in different 1906 SNMP engines, and to pass information between a transport mapping 1907 security model and a corresponding messaging security model. 1909 If the fields in an incoming SNMPv3 message are changed by the TMSP 1910 before passing it to the SMSP, then the TMSP will need to decode the 1911 ASN.1 message, modify the fields, and re-encode the message in ASN.1 1912 before passing the message on to the message dispatcher or to the 1913 transport layer. This would require an intimate knowledge of the 1914 message format and message versions so the TMSP knew which fields 1915 could be modified. This would seriously violate the modularity of 1916 the architecture. 1918 B.4. Using a Cache 1920 This document describes a cache, into which the TMSP puts information 1921 about the security applied to an incoming message, and an SMSP 1922 extracts that information from the cache. Given that there may be 1923 multiple TM-security caches, a tmSessionReference is passed as an 1924 extra parameter in the ASIs between the transport mapping and the 1925 messaging security model, so the SMSP knows which cache of 1926 information to consult. 1928 This approach does create dependencies between a model-specific TMSP 1929 and a corresponding specific SMSP. This approach of passing a model- 1930 independent reference is consistent with the securityStateReference 1931 cache already being passed around in the RFC3411 ASIs. 1933 Appendix C. Open Issues 1935 Appendix D. Change Log 1937 NOTE to RFC editor: Please remove this change log before publishing 1938 this document as an RFC. 1940 Changes from revision -02- to -03- 1942 o removed session table from MIB module 1943 o removed sessionID from ASIs 1944 o reorganized to put ASI discussions in EOP section, as was done in 1945 SSHSM 1946 o changed user auth to client auth 1947 o changed tmStateReference to tmSessionReference 1948 o modified document to meet consensus positions published by JS 1949 o 1950 * authoritative is model-specific 1951 * msgSecurityParameters usage is model-specific 1952 * msgFlags vs. securityLevel is model/implementation-specific 1953 * notifications must be able to cause creation of a session 1954 * security considerations must be model-specific 1955 * TDomain and TAddress are model-specific 1956 * MPSP changed to SMSP (Security model security processing) 1958 Changes from revision -01- to -02- 1960 o wrote text for session establishment requirements section. 1961 o wrote text for session maintenance requirements section. 1963 o removed section on relation to SNMPv2-MIB 1964 o updated MIB module to pass smilint 1965 o Added Structure of the MIB module, and other expected MIB-related 1966 sections. 1967 o updated author address 1968 o corrected spelling 1969 o removed msgFlags appendix 1970 o Removed section on implementation considerations. 1971 o started modifying the security boilerplate to address TMSM and MIB 1972 security issues 1973 o reorganized slightly to better separate requirements from proposed 1974 solution. This probably needs additional work. 1975 o removed section with sample protocols and sample 1976 tmSessionReference. 1977 o Added section for acronyms 1978 o moved section comparing parameter passing techniques to appendix. 1979 o Removed section on notification requirements. 1981 Changes from revision -00- 1982 o changed SSH references from I-Ds to RFCs 1983 o removed parameters from tmSessionReference for DTLS that revealed 1984 lower layer info. 1985 o Added TMSM-MIB module 1986 o Added Internet-Standard Management Framework boilerplate 1987 o Added Structure of the MIB Module 1988 o Added MIB security considerations boilerplate (to be completed) 1989 o Added IANA Considerations 1990 o Added ASI Parameter table 1991 o Added discussion of Sessions 1992 o Added Open issues and Change Log 1993 o Rearranged sections 1995 Authors' Addresses 1997 David Harrington 1998 Huawei Technologies (USA) 1999 1700 Alma Dr. Suite 100 2000 Plano, TX 75075 2001 USA 2003 Phone: +1 603 436 8634 2004 EMail: dharrington@huawei.com 2005 Juergen Schoenwaelder 2006 International University Bremen 2007 Campus Ring 1 2008 28725 Bremen 2009 Germany 2011 Phone: +49 421 200-3587 2012 EMail: j.schoenwaelder@iu-bremen.de 2014 Full Copyright Statement 2016 Copyright (C) The Internet Society (2006). 2018 This document is subject to the rights, licenses and restrictions 2019 contained in BCP 78, and except as set forth therein, the authors 2020 retain all their rights. 2022 This document and the information contained herein are provided on an 2023 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2024 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2025 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2026 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2027 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2028 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2030 Intellectual Property 2032 The IETF takes no position regarding the validity or scope of any 2033 Intellectual Property Rights or other rights that might be claimed to 2034 pertain to the implementation or use of the technology described in 2035 this document or the extent to which any license under such rights 2036 might or might not be available; nor does it represent that it has 2037 made any independent effort to identify any such rights. Information 2038 on the procedures with respect to rights in RFC documents can be 2039 found in BCP 78 and BCP 79. 2041 Copies of IPR disclosures made to the IETF Secretariat and any 2042 assurances of licenses to be made available, or the result of an 2043 attempt made to obtain a general license or permission for the use of 2044 such proprietary rights by implementers or users of this 2045 specification can be obtained from the IETF on-line IPR repository at 2046 http://www.ietf.org/ipr. 2048 The IETF invites any interested party to bring to its attention any 2049 copyrights, patents or patent applications, or other proprietary 2050 rights that may cover technology that may be required to implement 2051 this standard. Please address the information to the IETF at 2052 ietf-ipr@ietf.org. 2054 Acknowledgement 2056 Funding for the RFC Editor function is provided by the IETF 2057 Administrative Support Activity (IASA).