idnits 2.17.1 draft-ietf-isms-tmsm-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1967. ** 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 372 has weird spacing: '...patcher v ...' == Line 489 has weird spacing: '...message model...' == 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 (October 11, 2006) is 6407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3416' is defined on line 1644, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 5 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: April 14, 2007 International University Bremen 6 October 11, 2006 8 Transport Subsystem for the Simple Network Management Protocol (SNMP) 9 draft-ietf-isms-tmsm-04.txt 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 14, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes a Transport Subsystem, extending the Simple 43 Network Management Protocol (SNMP) architecture defined in RFC 3411. 44 This document describes a subsystem to contain transport models, 45 comparable to other subsystems in the RFC3411 architecture. As work 46 is being done to expand the transport to include secure transport 47 such as SSH and TLS, using a subsystem will enable consistent design 48 and modularity of such transport models. This document identifies 49 and discusses some key aspects that need to be considered for any 50 transport model for SNMP. 52 This memo also defines a portion of the Management Information Base 53 (MIB) for managing models in the Transport Subsystem. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. The Internet-Standard Management Framework . . . . . . . . 4 59 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Requirements of a Transport Model . . . . . . . . . . . . . . 6 63 2.1. Message Security Requirements . . . . . . . . . . . . . . 6 64 2.1.1. Security Protocol Requirements . . . . . . . . . . . . 6 65 2.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 7 66 2.2.1. Architectural Modularity Requirements . . . . . . . . 7 67 2.2.2. Access Control Requirements . . . . . . . . . . . . . 14 68 2.2.3. Security Parameter Passing Requirements . . . . . . . 16 69 2.3. Session Requirements . . . . . . . . . . . . . . . . . . . 17 70 2.3.1. Session Establishment Requirements . . . . . . . . . . 18 71 2.3.2. Session Maintenance Requirements . . . . . . . . . . . 19 72 2.3.3. Message security versus session security . . . . . . . 19 73 3. Scenario Diagrams for the Transport Subsystem . . . . . . . . 21 74 3.1. Command Generator or Notification Originator . . . . . . . 21 75 3.2. Command Responder . . . . . . . . . . . . . . . . . . . . 22 76 4. Cached Information and References . . . . . . . . . . . . . . 23 77 4.1. securityStateReference . . . . . . . . . . . . . . . . . . 24 78 4.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 25 79 5. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 25 80 5.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 26 81 5.2. Processing for an Outgoing Message . . . . . . . . . . . . 27 82 5.3. Processing an Incoming SNMP Message . . . . . . . . . . . 28 83 5.3.1. Processing an Incoming Message . . . . . . . . . . . . 28 84 5.3.2. Prepare Data Elements from Incoming Messages . . . . . 28 85 5.3.3. Processing an Incoming Message . . . . . . . . . . . . 29 86 6. The Transport-Subsystem-MIB Module . . . . . . . . . . . . . . 30 87 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 31 88 6.1.1. The tmsmStats Subtree . . . . . . . . . . . . . . . . 31 89 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 31 90 6.2.1. Textual Conventions . . . . . . . . . . . . . . . . . 31 91 6.2.2. MIB Modules Required for IMPORTS . . . . . . . . . . . 31 92 6.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 97 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 98 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 99 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 39 100 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 39 101 Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 41 102 B.1. Define an Abstract Service Interface . . . . . . . . . . . 41 103 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 41 104 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 42 105 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 42 106 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 42 107 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 42 109 1. Introduction 111 This document describes a Transport Subsystem, extending the Simple 112 Network Management Protocol (SNMP) architecture defined in [RFC3411]. 113 This document identifies and discusses some key aspects that need to 114 be considered for any transport model for SNMP. 116 1.1. The Internet-Standard Management Framework 118 For a detailed overview of the documents that describe the current 119 Internet-Standard Management Framework, please refer to section 7 of 120 RFC 3410 [RFC3410]. 122 Managed objects are accessed via a virtual information store, termed 123 the Management Information Base or MIB. MIB objects are generally 124 accessed through the Simple Network Management Protocol (SNMP). 125 Objects in the MIB are defined using the mechanisms defined in the 126 Structure of Management Information (SMI). This memo specifies a MIB 127 module that is compliant to the SMIv2, which is described in STD 58, 128 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 129 [RFC2580]. 131 1.2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 Some points requiring further WG research and discussion are 138 identified by [discuss] markers in the text. Some points requiring 139 further editing by the editors are marked [todo] in the text. 141 1.3. Acronyms 143 This section contains a list of acronyms used within the document and 144 references to where in the document the acronym is defined, for easy 145 lookup. 146 o [todo] 148 1.4. Motivation 150 There are multiple ways to secure one's home or business, in a 151 continuum of alternatives. Let's consider three general approaches. 152 In the first approach, an individual could buy a gun, learn to use 153 it, and sit on your front porch waiting for intruders. In the second 154 approach, one could hire an employee with a gun, schedule the 155 employee, position the employee to guard what you want protected, 156 hire a second guard to cover if the first gets sick, and so on. In 157 the third approach, you could hire a security company, tell them what 158 you want protected, and they could hire employees, train them, buy 159 the guns, position the guards, schedule the guards, send a 160 replacement when a guard cannot make it, etc., thus providing the 161 security you want, with no significant effort on your part other than 162 identifying requirements and verifying the quality of the service 163 being provided. 165 The User-based Security Model (USM) as defined in [RFC3414] largely 166 uses the first approach - it provides its own security. It utilizes 167 existing mechanisms (MD5=the gun), but provides all the coordination. 168 USM provides for the authentication of a principal, message 169 encryption, data integrity checking, timeliness checking, etc. 171 USM was designed to be independent of other existing security 172 infrastructures. USM therefore requires a separate principal and key 173 management infrastructure. Operators have reported that deploying 174 another principal and key management infrastructure in order to use 175 SNMPv3 is a deterrent to deploying SNMPv3. It is possible but 176 difficult to define external mechanisms that handle the distribution 177 of keys for use by the USM approach. 179 A solution based on the second approach might use a USM-compliant 180 architecture, but combine the authentication mechanism with an 181 external mechanism, such as RADIUS [RFC2865], to provide the 182 authentication service. It might be possible to utilize an external 183 protocol to encrypt a message, to check timeliness, to check data 184 integrity, etc. It is difficult to cobble together a number of 185 subcontracted services and coordinate them however, because it is 186 difficult to build solid security bindings between the various 187 services, and potential for gaps in the security is significant. 189 A solution based on the third approach might utilize one or more 190 lower-layer security mechanisms to provide the message-oriented 191 security services required. These would include authentication of 192 the sender, encryption, timeliness checking, and data integrity 193 checking. There are a number of IETF standards available or in 194 development to address these problems through security layers at the 195 transport layer or application layer, among them TLS [RFC4366], SASL 196 [RFC4422], and SSH [RFC4251]. 198 From an operational perspective, it is highly desirable to use 199 security mechanisms that can unify the administrative security 200 management for SNMPv3, command line interfaces (CLIs) and other 201 management interfaces. The use of security services provided by 202 lower layers is the approach commonly used for the CLI, and is also 203 the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. 205 This document describes a Transport Subsystem extension to the 206 RFC3411 architecture, that allows security to be provided by an 207 external protocol connected to the SNMP engine through an SNMP 208 transport-model [RFC3417]. Such a transport model would then enable 209 the use of existing security mechanisms such as (TLS) [RFC4366] or 210 SSH [RFC4251] within the RFC3411 architecture. 212 There are a number of Internet security protocols and mechanisms that 213 are in wide spread use. Many of them try to provide a generic 214 infrastructure to be used by many different application layer 215 protocols. The motivation behind the transport subsystem is to 216 leverage these protocols where it seems useful. 218 There are a number of challenges to be addressed to map the security 219 provided by a secure transport into the SNMP architecture so that 220 SNMP continues to work without any surprises. These challenges are 221 discussed in detail in this document. For some key issues, design 222 choices are discussed that may be made to provide a workable solution 223 that meets operational requirements and fits into the SNMP 224 architecture defined in [RFC3411]. 226 2. Requirements of a Transport Model 228 2.1. Message Security Requirements 230 Transport security protocols SHOULD ideally provide the protection 231 against the following message-oriented threats [RFC3411]: 233 1. modification of information 234 2. masquerade 235 3. message stream modification 236 4. disclosure 238 According to [RFC3411], it is not required to protect against denial 239 of service or traffic analysis. 241 2.1.1. Security Protocol Requirements 243 There are a number of standard protocols that could be proposed as 244 possible solutions within the transport subsystem. Some factors 245 should be considered when selecting a protocol. 247 Using a protocol in a manner for which it was not designed has 248 numerous problems. The advertised security characteristics of a 249 protocol may depend on its being used as designed; when used in other 250 ways, it may not deliver the expected security characteristics. It 251 is recommended that any proposed model include a discussion of the 252 applicability statement of the protocols to be used. 254 A transport model should require no modifications to the underlying 255 protocol. Modifying the protocol may change its security 256 characteristics in ways that would impact other existing usages. If 257 a change is necessary, the change should be an extension that has no 258 impact on the existing usages. It is recommended that any transport 259 model include a discussion of potential impact on other usages of the 260 protocol. 262 It has been a long-standing requirement that SNMP be able to work 263 when the network is unstable, to enable network troubleshooting and 264 repair. The UDP approach has been considered to meet that need well, 265 with an assumption that getting small messages through, even if out 266 of order, is better than getting no messages through. There has been 267 a long debate about whether UDP actually offers better support than 268 TCP when the underlying IP or lower layers are unstable. There has 269 been recent discussion of whether operators actually use SNMP to 270 troubleshoot and repair unstable networks. 272 There has been discussion of ways SNMP could be extended to better 273 support management/monitoring needs when a network is running just 274 fine. Use of a TCP transport, for example, could enable larger 275 message sizes and more efficient table retrievals. 277 Transport models MUST be able to coexist with other transport models, 278 and may be designed to utilize either TCP or UDP or SCTP. 280 2.2. SNMP Requirements 282 2.2.1. Architectural Modularity Requirements 284 SNMP version 3 (SNMPv3) is based on a modular architecture (described 285 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 286 standards over time, and to minimize side effects between subsystems 287 when changes are made. 289 The RFC3411 architecture includes a security subsystem for enabling 290 different methods of providing security services, a messaging 291 subsystem permitting different message versions to be handled by a 292 single engine, an application subsystem to support different types of 293 application processors, and an access control subsystem for allowing 294 multiple approaches to access control. The RFC3411 architecture does 295 not include a subsystem for transport models, despite the fact there 296 are multiple transport mappings already defined for SNMP. This 297 document addresses the need for a transport subsystem compatible with 298 the RFC3411 architecture. 300 In SNMPv2, there were many problems of side effects between 301 subsystems caused by the manipulation of MIB objects, especially 302 those related to authentication and authorization, because many of 303 the parameters were stored in shared MIB objects, and different 304 models and protocols could assign different values to the objects. 305 Contributors assumed slightly different shades of meaning depending 306 on the models and protocols being used. As the shared MIB module 307 design was modified to accommodate a specific model, other models 308 which used the same MIB objects would be broken. 310 Abstract Service Interfaces (ASIs) were developed to pass model- 311 independent parameters. The models were required to translate from 312 their model-dependent formats into a model-independent format, 313 defined using model-independent semantics, which would not impact 314 other models. 316 Parameters have been provided in the ASIs to pass model-independent 317 information about the authentication that has been provided. These 318 parameters include a model-independent identifier of the security 319 "principal", the security model used to perform the authentication, 320 and which SNMP-specific security features were applied to the message 321 (authentication and/or privacy). 323 Parameters have been provided in the ASIs to pass model-independent 324 transport address information. These parameters utilize the 325 TransportType and TransportAddress 327 The design of a transport subsystem must abide the goals of the 328 RFC3411 architecture defined in [RFC3411]. To that end, this 329 transport subsystem proposal uses a modular design that will permit 330 transport models to be advanced through the standards process 331 independently of other transport models, and independent of other 332 modular SNMP components as much as possible. 334 IETF standards typically require one mandatory to implement solution, 335 with the capability of adding new mechanisms in the future. Part of 336 the motivstion of developing transport models is to develop support 337 for secure transport protocols, such as a transport model that 338 utilizes the Secure Shell protocol. Any transport model should 339 define one minimum-compliance security mechanism, preferably one 340 which is already widely used to secure the transport layer protocol. 342 The Transport Subsystem permits multiple transport protocols to be 343 "plugged into" the RFC3411 architecture, supported by corresponding 344 transport models, including models that are security-aware. 346 The RFC3411 architecture,and the USM assume that a security model is 347 called by a message-processing model and will perform multiple 348 security functions within the security subsystem. A transport model 349 that supports a secure transport protocol may perform similar 350 security functions within the transport subsystem. A transport model 351 may perform the translation of transport security parameters to/from 352 security-model-independent parameters. To accommodate this, the ASIs 353 for the transport subsystem, the messaging subsystem, and the 354 security subsystem will be extended to pass security-model- 355 independent values, and a cache of transport-specific information. 357 +------------------------------+ 358 | Network | 359 +------------------------------+ 360 ^ ^ ^ 361 | | | 362 v v v (traditional SNMP agent) 363 +-------------------------------------------------------------------+ 364 | +--------------------------------------------------+ | 365 | | Transport Subsystem | | 366 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 367 | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | 368 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 369 | +--------------------------------------------------+ | 370 | ^ | 371 | | | 372 | Dispatcher v | 373 | +-------------------+ +---------------------+ +----------------+ | 374 | | | | Message Processing | | Security | | 375 | | | | Subsystem | | Subsystem | | 376 | | | | +------------+ | | +------------+ | | 377 | | | | +->| v1MP * |<--->| | USM * | | | 378 | | | | | +------------+ | | +------------+ | | 379 | | | | | +------------+ | | +------------+ | | 380 | | | | +->| v2cMP * |<--->| | Transport* | | | 381 | | Message | | | +------------+ | | | Security | | | 382 | | Dispatcher <--------->| +------------+ | | | Model | | | 383 | | | | +->| v3MP * |<--->| +------------+ | | 384 | | | | | +------------+ | | +------------+ | | 385 | | PDU Dispatcher | | | +------------+ | | | Other * | | | 386 | +-------------------+ | +->| otherMP * |<--->| | Model(s) | | | 387 | ^ | +------------+ | | +------------+ | | 388 | | +---------------------+ +----------------+ | 389 | v | 390 | +-------+-------------------------+---------------+ | 391 | ^ ^ ^ | 392 | | | | | 393 | v v v | 394 | +-------------+ +---------+ +--------------+ +-------------+ | 395 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 396 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 397 | | application | | | | applications | | application | | 398 | +-------------+ +---------+ +--------------+ +-------------+ | 399 | ^ ^ | 400 | | | | 401 | v v | 402 | +----------------------------------------------+ | 403 | | MIB instrumentation | SNMP entity | 404 +-------------------------------------------------------------------+ 406 2.2.1.1. USM and the RFC3411 Architecture 408 The following diagrams illustrate the difference in the security 409 processing done by the USM model and the security processing 410 potentially done by a transport model. 412 The USM security model is encapsulated by the messaging model, 413 because the messaging model needs to perform the following steps (for 414 incoming messages) 415 1) decode the ASN.1 (messaging model) 416 2) determine the SNMP security model and parameters (messaging model) 417 3) decrypt the encrypted portions of the message (security model) 418 4) translate parameters to model-independent parameters (security 419 model) 420 5) determine which application should get the decrypted portions 421 (messaging model), and 422 6) pass on the decrypted portions with model-independent parameters. 424 The USM approach uses SNMP-specific message security and parameters. 426 | -----------------------------------------------| 427 | transport layer | 428 | -----------------------------------------------| 429 ^ 430 | 431 v 432 -------------------------------------------------- 433 | -----------------------------------------------| 434 | | transport mapping | 435 | -----------------------------------------------| 436 | ^ 437 | | 438 | v 439 | --------------------------------------------- | 440 | --------------------- ------------------ | 441 | SNMP messaging <--> | decryption + | | 442 | | translation | | 443 | --------------------- ------------------ | 444 | ^ 445 | | 446 | v 447 | --------------------- ------------------ | 448 | | SNMP applications | <--> | access control | | 449 | --------------------- ------------------ | 451 | --------------------------------------------- | 453 2.2.1.2. Transport Subsystem and the RFC3411 Architecture 455 With the Transport Subsystem, the order of the steps may differ and 456 may be handled by different subsystems: 457 1) decrypt the encrypted portions of the message (transport layer) 458 2*) translate parameters to model-independent parameters (transport 459 model) 460 3) determine the SNMP security model and parameters (messaging model) 461 4) decode the ASN.1 (messaging model) 462 5) determine which application should get the decrypted portions 463 (messaging model) 464 7) pass on the decrypted portions with model-independent security 465 parameters 467 If a message is secured using non-SNMP-specific message security and 468 parameters, then the transport model should provide the translation 469 from e.g., an SSH user name to the securityName in step 3, 470 | -----------------------------------------------| 471 | ------------------ | 472 | transport layer <--> | decryption | | 473 | ------------------ | 474 | -----------------------------------------------| 475 ^ 476 | 477 v 478 -------------------------------------------------- 479 | -----------------------------------------------| 480 | ------------------ | 481 | transport model <--> | translation | | 482 | ------------------ | 483 | -----------------------------------------------| 484 | ^ 485 | | 486 | v 487 | --------------------------------------------- | 488 | | 489 | message model | 490 | | 491 | -----------------------------------------------| 492 | ^ 493 | | 494 | v 495 | --------------------------------------------- | 496 | | 497 | security model | 498 | | 499 | -----------------------------------------------| 500 | ^ 501 | | 502 | v 503 | --------------------- ------------------ | 504 | | SNMP applications | <--> | access control | | 505 | --------------------- ------------------ | 507 | --------------------------------------------- | 509 2.2.1.3. Passing Information between Engines 511 A secure transport model will establish an encrypted tunnel between 512 the transport models of two SNMP engines. One transport model 513 instance encrypts all messages, and the other transport model 514 instance decrypts the messages. 516 After a transport layer tunnel is established, then SNMP messages can 517 conceptually be sent through the tunnel from one SNMP engine to 518 another SNMP engine. Once the tunnel is established, multiple SNMP 519 messages may be able to be passed through the same tunnel. 521 2.2.2. Access Control Requirements 523 2.2.2.1. securityName Binding 525 For SNMP access control to function properly, security processing 526 must establish a securityModel identifier, a securityLevel, and a 527 securityName, which is the security model independent identifier for 528 a principal. The message processing subsystem relies on a security 529 model, such as USM, to play a role in security that goes beyond 530 protecting the message - it provides a mapping between the USM- 531 specific principal to a security-model independent securityName which 532 can be used for subsequent processing, such as for access control. 534 The securityName MUST be bound to the mechanism-specific 535 authenticated identity, and this mapping MUST be done for incoming 536 messages before the security model passes securityName to the message 537 processing model via the processIncoming() ASI. This translation 538 from a mechanism-specific authenticated identity to a securityName 539 MAY be done by the transport model, and the securityname is then 540 provided to the security model to be passed to the message processing 541 model.. 543 If the type of authentication provided by the transport layer (e.g. 544 TLS) is considered adequate to secure and/or encrypt the message, but 545 inadequate to provide the desired granularity of access control (e.g. 546 user-based), then a second authentication (e.g., one provided via a 547 RADIUS server) MAY be used to provide the authentication identity 548 which is bound to the securityName. This approach would require a 549 good analysis of the potential for man-in-the-middle attacks or 550 masquerade possibilities. 552 2.2.2.2. Separation of Authentication and Authorization 554 A transport model that provides security services should take care to 555 not violate the separation of authentication and authorization in the 556 RFC3411 architecture. The isAccessAllowed() primitive is used for 557 passing security-model independent parameters between the subsystems 558 of the architecture. 560 Mapping of (securityModel, securityName) to an access control policy 561 should be handled within the access control subsystem, not the 562 transport or security subsystems, to be consistent with the 563 modularity of the RFC3411 architecture. This separation was a 564 deliberate decision of the SNMPv3 WG, to allow support for 565 authentication protocols which did not provide authorization 566 capabilities, and to support authorization schemes, such as VACM, 567 that do not perform their own authentication. 569 An authorization model (in the access control subsystem) MAY require 570 authentication by certain securityModels and a minimum securityLevel 571 to allow access to the data. 573 Transport models that provide secure transport are an enhancement for 574 the SNMPv3 privacy and authentication, but they are not a significant 575 improvement for the authorization (access control) needs of SNMPv3. 576 Only the model-independent parameters for the isAccessAllowed() 577 primitive [RFC3411] are provided by the transport and security 578 subsystems. 580 A transport model must not specify how the securityModel and 581 securityName could be dynamically mapped to an access control 582 mechanism, such as a VACM-style groupName. The mapping of 583 (securityModel, securityName) to a groupName is a VACM-specific 584 mechanism for naming an access control policy, and for tying the 585 named policy to the addressing capabilities of the data modeling 586 language (e.g. SMIv2 [RFC2578]), the operations supported, and other 587 factors. Providing a binding outside the Access Control subsystem 588 might create dependencies that could make it harder to develop 589 alternate models of access control, such as one built on UNIX groups 590 or Windows domains. The preferred approach is to pass the model- 591 independent security parameters via the isAccessAllowed() ASI, and 592 perform the mapping from the model-independent security parameters to 593 an authorization-model-dependent access policy within the access 594 control model. 596 To provide support for protocols which simultaneously send 597 information for authentication and authorization, such as RADIUS 598 [RFC2865], model-specific authorization information MAY be cached or 599 otherwise made available to the access control subsystem, e.g., via a 600 MIB table similar to the vacmSecurityToGroupTable, so the access 601 control subsystem can create an appropriate binding between the 602 model-independent securityModel and securityName and a model-specific 603 access control policy. This may be highly undesirable, however, if 604 it creates a dependency between a transport model or a security model 605 and an access control model, just as it is undesirable for a 606 transport model to create a dependency between an SNMP message 607 version and the security provided by a transport model. 609 2.2.3. Security Parameter Passing Requirements 611 RFC3411 section 4 describes primitives to describe the abstract data 612 flows between the various subsystems, models and applications within 613 the architecture. Abstract Service Interfaces describe the flow of 614 data between subsystems within an engine. The ASIs generally pass 615 model-independent information. 617 Within an engine using a transport model, outgoing SNMP messages are 618 passed unencrypted from the message dispatcher to the transport 619 model, and incoming messages are passed unencrypted from the 620 transport model to the message dispatcher. 622 The security parameters include a model-independent identifier of the 623 security "principal", the security model used to perform the 624 authentication, and which SNMP-specific security services were 625 (should be) applied to the message (authentication and/or privacy). 627 In the RFC3411 architecture, which reflects the USM security model 628 design, the messaging model must unpack SNMP-specific security 629 parameters from an incoming message before calling a specific 630 security model to authenticate and decrypt an incoming message, 631 perform integrity checking, and translate model-specific security 632 parameters into model-independent parameters. 634 When using a secure transport model, security parameters MAY be 635 provided through means other than carrying them in the SNMP message. 636 The parameters MAY be provided by SNMP applications for outgoing 637 messages, and the parameters for incoming messages MAY be extracted 638 from the transport layer by the transport model before the message is 639 passed to the message processing subsystem. 641 For outgoing messages, even when a secure transport model will 642 provide the security services, it is necessary to have an security 643 model because it is the security model that actually creates the 644 message from its component parts. Whether there are any security 645 services provided by the security model for an outgoing message is 646 model-dependent. 648 For incoming messages, even when a secure transport model provides 649 security services, a security model is necessary because there might 650 be some security functionality that can only be provided after the 651 message version is known. The message version is determined by the 652 Message Processing model and passed to the security model via the 653 processIncoming() ASI. 655 The RFC3411 architecture has no ASI parameters for passing security 656 information between a transport mapping (a transport model) and the 657 dispatcher, and between the dispatcher and the message processing 658 model. 660 This document describes a cache mechanism, into which the transport 661 model puts information about the transport and security parameters 662 applied to a transport connection or an incoming message, and a 663 security model MAY extract that information from the cache. A 664 tmStateReference is passed as an extra parameter in the ASIs of the 665 transport subsystem and the messaging and security subsystems, to 666 identify the relevant cache. 668 This approach of passing a model-independent reference is consistent 669 with the securityStateReference cache already being passed around in 670 the RFC3411 ASIs. [todo: can we avoid dependencies?] 672 2.3. Session Requirements 674 Throughout this document, the term session is used. Some underlying 675 secure transports will have a notion of session. Some underlying 676 secure transports might enable the use of channels or other session- 677 like thing. In this document the term session refers to an 678 association between two SNMP engines that permits the secure 679 transmission of one or more SNMP messages within the lifetime of the 680 session. How the session is actually established, opened, closed, or 681 maintained is specific to a particular transport model. 683 Sessions are not part of the SNMP architecture described in 684 [RFC3411], but are considered desirable because the cost of 685 authentication can be amortized over potentially many transactions. 687 It is important to note that the architecture described in [RFC3411] 688 does not include a session selector in the Abstract Service 689 Interfaces, and neither is that done for the transport subsystem, so 690 an SNMP application cannot select the session except by passing a 691 unique combination of transport type, transport address, 692 securityName, securityModel, and securityLevel. 694 All transport models should discuss the impact of sessions on SNMP 695 usage, including how to establish/open a transport session (i.e., how 696 it maps to the concepts of session-like things of the underlying 697 protocol), how to behave when a session cannot be established, how to 698 close a session properly, how to behave when a session is closed 699 improperly, the session security properties, session establishment 700 overhead, and session maintenance overhead. 702 To reduce redundancy, this document will discuss aspects that are 703 expected to be common to all transport model sessions. 705 2.3.1. Session Establishment Requirements 707 SNMP applications must provide the transport type, transport address, 708 securityName, securityModel, and securityLevel to be used for a 709 session. 711 SNMP Applications typically have no knowledge of whether the session 712 that will be used to carry commands was initially established as a 713 notification session, or a request-response session, and SHOULD NOT 714 make any assumptions based on knowing the direction of the session. 715 If an administrator or transport model designer wants to 716 differentiate a session established for different purposes, such as a 717 notification session versus a request-response session, the 718 application can use different securityNames or transport addresses 719 (e.g., port 161 vs. port 162) for different purposes. 721 An SNMP engine containing an application that initiates 722 communication, e.g., a Command Generator or Notification Originator, 723 MUST be able to attempt to establish a session for delivery if a 724 session does not yet exist. If a session cannot be established then 725 the message is discarded. 727 Sessions are usually established by the transport model when no 728 appropriate session is found for an outgoing message, but sessions 729 may be established in advance to support features such as 730 notifications. How sessions are established in advance is beyond the 731 scope of this document. 733 Sessions are initiated by notification originators when there is no 734 currently established connection that can be used to send the 735 notification. For a client-server security protocol, this may 736 require provisioning authentication credentials on the agent, either 737 statically or dynamically, so the client/agent can successfully 738 authenticate to a notification receiver. 740 A transport model must be able to determine whether a session does or 741 does not exist, and must be able to determine which session has the 742 appropriate security characteristics (transport type, transport 743 address, securityName, securityModel, and securityLevel) for an 744 outgoing message. [discuss: does the transport model have insight 745 into the securityModel?] 747 A transport model implementation MAY reuse an already established 748 session with the appropriate transport type, transport address, 749 securityName, securityModel, and securityLevel characteristics for 750 delivery of a message originated by a different type of application 751 than originally caused the session to be created. For example, an 752 implementation that has an existing session originally established to 753 receive a request may use that session to send an outgoing 754 notification, and may use a session that was originally established 755 to send a notification to send a request. Responses are expected to 756 be returned using the same session that carried the corresponding 757 request message. Reuse of sessions is not required for conformance. 759 If a session can be reused for a different type of message, but a 760 receiver is not prepared to accept different message types over the 761 same session, then the message MAY be dropped by the receiver. This 762 may strongly affect the usefulness of session reuse. 764 2.3.2. Session Maintenance Requirements 766 A transport model can tear down sessions as needed. It may be 767 necessary for some implementations to tear down sessions as the 768 result of resource constraints, for example. 770 The decision to tear down a session is implementation-dependent. 771 While it is possible for an implementation to automatically tear down 772 each session once an operation has completed, this is not recommended 773 for anticipated performance reasons. How an implementation 774 determines that an operation has completed, including all potential 775 error paths, is implementation-dependent. 777 Implementations should be careful to not tear down a session between 778 the time a request is received and the time the response is sent. 779 The elements of procedure for transport models should be sure to 780 describe the expected behavior when no session exists for a response. 781 [todo: do we already say that the message should be discarded, or is 782 that just in the ssh transport model?] 784 The elements of procedure may discuss when cached information can be 785 discarded, and the timing of cache cleanup may have security 786 implications, but cache memory management is an implementation issue. 788 If a transport model defines MIB module objects to maintain session 789 state information, then the transport model MUST describe what 790 happens to the objects when a related session is torn down, since 791 this will impact interoperability of the MIB module. 793 2.3.3. Message security versus session security 795 A transport model session is associated with state information that 796 is maintained for its lifetime. This state information allows for 797 the application of various security services to multiple messages. 798 Cryptographic keys established at the beginning of the session SHOULD 799 be used to provide authentication, integrity checking, and encryption 800 services for data that is communicated during the session. The 801 cryptographic protocols used to establish keys for a transport model 802 session SHOULD ensure that fresh new session keys are generated for 803 each session. If each session uses new session keys, then messages 804 cannot be replayed from one session to another. In addition sequence 805 information MAY be maintained in the session which can be used to 806 prevent the replay and reordering of messages within a session. 808 A transport model session will typically have a single transport 809 type, ransport address, securityModel, securityName and securityLevel 810 associated with it. If an exchange between communicating engines 811 would require a different securityLevel or would be on behalf of a 812 different securityName, or to use a different securityModel, then 813 another session would be needed. An immediate consequence of this is 814 that implementations should be able to maintain some reasonable 815 number of concurrent sessions. 817 For transport models, securityName is typically specified during 818 session setup, and associated with the session identifier. 820 SNMPv3 was designed to support multiple levels of security, 821 selectable on a per-message basis by an SNMP application, because 822 there is not much value in using encryption for a Commander Generator 823 to poll for non-sensitive performance data on thousands of interfaces 824 every ten minutes; the encryption adds significant overhead to 825 processing of the messages. 827 Some transport models MAY support only specific authentication and 828 encryption services, such as requiring all messages to be carried 829 using both authentication and encryption, regardless of the security 830 level requested by an SNMP application. 832 Some transport models may use an underlying transport that provides a 833 per-message requested level of authentication and encryption 834 services. For example, if a session is created as 'authPriv', then 835 keys for encryption could still be negotiated once at the beginning 836 of the session. But if a message is presented to the session with a 837 security level of authNoPriv, then that message could simply be 838 authenticated and not encrypted within the same transport session. 839 Whether this is possible depends on the transport model and the 840 secure transport used. 842 If the underlying transport layer security is configurable on a per- 843 message basis, a transport model could have a transport-model MIB 844 module with configurable maxSecurityLevel and a minSecurityLevel 845 objects to identify the range of possible levels. A session's 846 maxSecurityLevel would identify the maximum security it could 847 provide, and a session created with a minSecurityLevel of authPriv 848 would reject an attempt to send an authNoPriv message. The elements 849 of procedure of the transport model would need to describe the 850 procedures to enable this determination. [discuss: this is a feature 851 I find questionable. It can be developed as a feature of a specific 852 transport model. Do we need this discussion here?] 854 For transport models that do not support variable security services 855 in one session, multiple sessions could be established with different 856 security levels, and for every packet the SNMP engine could select 857 the appropriate session based on the requested securityLevel. Some 858 SNMP entities are resource-constrained. Adding sessions increases 859 the need for resources, but so does encrypting unnecessarily. 860 Designers of transport models should consider the trade offs for 861 resource-constrained devices. 863 3. Scenario Diagrams for the Transport Subsystem 865 RFC3411 section 4.6 provides scenario diagrams to illustrate how an 866 outgoing message is created, and how an incoming message is 867 processed. Both diagrams are incomplete, however. In section 4.6.1, 868 the diagram doesn't show the ASI for sending an SNMP request to the 869 network or receiving an SNMP response message from the network. In 870 section 4.6.2, the diagram doesn't illustrate the interfaces required 871 to receive an SNMP message from the network, or to send an SNMP 872 message to the network. 874 3.1. Command Generator or Notification Originator 876 This diagram from RFC3411 4.6.1 shows how a Command Generator or 877 Notification Originator application [RFC3413] requests that a PDU be 878 sent, and how the response is returned (asynchronously) to that 879 application. 881 Command Dispatcher Message Security 882 Generator | Processing Model 883 | | Model | 884 | sendPdu | | | 885 |------------------->| | | 886 | | prepareOutgoingMessage | | 887 : |----------------------->| | 888 : | | generateRequestMsg | 889 : | |-------------------->| 890 : | | | 891 : | |<--------------------| 892 : | | | 893 : |<-----------------------| | 894 : | | | 895 : |------------------+ | | 896 : | Send SNMP | | | 897 : | Request Message | | | 898 : | to Network | | | 899 : | v | | 900 : : : : : 901 : : : : : 902 : : : : : 903 : | | | | 904 : | Receive SNMP | | | 905 : | Response Message | | | 906 : | from Network | | | 907 : |<-----------------+ | | 908 : | | | 909 : | prepareDataElements | | 910 : |----------------------->| | 911 : | | processIncomingMsg | 912 : | |-------------------->| 913 : | | | 914 : | |<--------------------| 915 : | | | 916 : |<-----------------------| | 917 | processResponsePdu | | | 918 |<-------------------| | | 919 | | | | 921 3.2. Command Responder 923 This diagram shows how a Command Responder or Notification Receiver 924 application registers for handling a pduType, how a PDU is dispatched 925 to the application after an SNMP message is received, and how the 926 Response is (asynchronously) send back to the network. 928 Command Dispatcher Message Security 929 Responder | Processing Model 930 | | Model | 931 | | | | 932 | registerContextEngineID | | | 933 |------------------------>| | | 934 |<------------------------| | | | 935 | | Receive SNMP | | | 936 : | Message | | | 937 : | from Network | | | 938 : |<-------------+ | | 939 : | | | 940 : |prepareDataElements | | 941 : |------------------->| | 942 : | | processIncomingMsg | 943 : | |------------------->| 944 : | | | 945 : | |<-------------------| 946 : | | | 947 : |<-------------------| | 948 | processPdu | | | 949 |<------------------------| | | 950 | | | | 951 : : : : 952 : : : : 953 | returnResponsePdu | | | 954 |------------------------>| | | 955 : | prepareResponseMsg | | 956 : |------------------->| | 957 : | |generateResponseMsg | 958 : | |------------------->| 959 : | | | 960 : | |<-------------------| 961 : | | | 962 : |<-------------------| | 963 : | | | 964 : |--------------+ | | 965 : | Send SNMP | | | 966 : | Message | | | 967 : | to Network | | | 968 : | v | | 970 4. Cached Information and References 972 The RFC3411 architecture uses caches to store dynamic model-specific 973 information, and uses references in the ASIs to indicate in a model- 974 independent manner which cached information must flow between 975 subsystems. 977 There are two levels of state that may need to be maintained: the 978 security state in a request-response pair, and potentially long-term 979 state relating to transport and security. 981 This state is maintained in caches and a Local Configuration 982 Datastore (LCD). To simplify the elements of procedure, the release 983 of state information is not always explicitly specified. As a 984 general rule, if state information is available when a message being 985 processed gets discarded, the state related to that message should 986 also be discarded, and if state information is available when a 987 relationship between engines is severed, such as the closing of a 988 transport session, the state information for that relationship might 989 also be discarded. 991 This document differentiates the tmStateReference from the 992 securityStateReference. This document does not specify an 993 implementation strategy, only an abstract discussion of the data that 994 must flow between subsystems. An implementation MAY use one cache 995 and one reference to serve both functions, but an implementer must be 996 aware of the cache-release issues to prevent the cache from being 997 released before a security or transport model has had an opportunity 998 to extract the information it needs. 1000 4.1. securityStateReference 1002 From RFC3411: "For each message received, the Security Model caches 1003 the state information such that a Response message can be generated 1004 using the same security information, even if the Local Configuration 1005 Datastore is altered between the time of the incoming request and the 1006 outgoing response. 1008 A Message Processing Model has the responsibility for explicitly 1009 releasing the cached data if such data is no longer needed. To 1010 enable this, an abstract securityStateReference data element is 1011 passed from the Security Model to the Message Processing Model. The 1012 cached security data may be implicitly released via the generation of 1013 a response, or explicitly released by using the stateRelease 1014 primitive, as described in RFC3411 section 4.5.1." 1016 The information saved should include the model-independent parameters 1017 (transportType, transportAddress, securityName, securityModel, and 1018 securityLevel), related security parameters, and other information 1019 needed to imatch the response with the request. The Message 1020 Processing Model has the responsibility for explicitly releasing the 1021 securityStateReference when such data is no longer needed. The 1022 securityStateReference cached data may be implicitly released via the 1023 generation of a response, or explicitly released by using the 1024 stateRelease primitive, as described in RFC 3411 section 4.5.1." 1026 If the transport model connection is closed between the time a 1027 Request is received and a Response message is being prepared, then 1028 the Response message MAY be discarded. 1030 4.2. tmStateReference 1032 For each message or transport session, information about the message 1033 security is stored in the Local Configuration Datastore (LCD), 1034 supplemented with a cache, to pass model- and mechanism-specific 1035 parameters. The state referenced by tmStateReference may be saved 1036 across multiple messages, as compared to securityStateReference which 1037 is only saved for the life of a request-response pair of messages. 1039 The format of the cache and the LCD are implementation-specific. For 1040 ease of explanation, this document defines a MIB module to 1041 conceptually represent the LCD, but this is not meant to contrain 1042 implementations from doing it differently. 1044 It is expected that the LCD will allow lookup based on the 1045 combination of transportType, transportAddress, securityName, 1046 securityModel, and securityLevel. It is expected that the cache 1047 contain these values or contain pointers/references to entries in the 1048 LCD. 1050 It is expected that a transport model may store transport-specific 1051 parameters in the LCD for subsequent usage. 1053 5. Abstract Service Interfaces 1055 [todo: the discussion of ASIs that are not directly related to the 1056 transport or security models was added to the document because it was 1057 difficult to understand what information was available at what 1058 points, and who provided the information. The presence of this 1059 expository text can make it hard to find the relevant ASIs for the 1060 transport subsystem, and can be confusing because it talks about 1061 things that the transport subsystem should not know about. This text 1062 should be reduced. 1064 Abstract service interfaces have been defined by RFC 3411 to describe 1065 the conceptual data flows between the various subsystems within an 1066 SNMP entity. 1068 To simplify the elements of procedure, the release of state 1069 information is not always explicitly specified. As a general rule, 1070 if state information is available when a message gets discarded, the 1071 message-state information should also be released, and if state 1072 information is available when a session is closed, the session state 1073 information should also be released. 1075 An error indication may return an OID and value for an incremented 1076 counter and a value for securityLevel, and values for contextEngineID 1077 and contextName for the counter, and the securityStateReference if 1078 the information is available at the point where the error is 1079 detected. 1081 5.1. Generating an Outgoing SNMP Message 1083 This section describes the procedure followed by an RFC3411- 1084 compatible system whenever it generates a message containing a 1085 management operation (such as a request, a response, a notification, 1086 or a report) on behalf of a user. 1088 statusInformation = -- success or errorIndication 1089 prepareOutgoingMessage( 1090 IN transportDomain -- transport domain to be used 1091 IN transportAddress -- transport address to be used 1092 IN messageProcessingModel -- typically, SNMP version 1093 IN securityModel -- Security Model to use 1094 IN securityName -- on behalf of this principal 1095 IN securityLevel -- Level of Security requested 1096 IN contextEngineID -- data from/at this entity 1097 IN contextName -- data from/in this context 1098 IN pduVersion -- the version of the PDU 1099 IN PDU -- SNMP Protocol Data Unit 1100 IN expectResponse -- TRUE or FALSE 1101 IN sendPduHandle -- the handle for matching 1102 incoming responses 1103 OUT destTransportDomain -- destination transport domain 1104 OUT destTransportAddress -- destination transport address 1105 OUT outgoingMessage -- the message to send 1106 OUT outgoingMessageLength -- its length 1107 OUT tmStateReference 1108 ) 1110 Note that tmStateReference has been added to this ASI. 1112 The IN parameters of the prepareOutgoingMessage() ASI are used to 1113 pass information from the dispatcher (for the application subsystem) 1114 to the message processing subsystem. 1116 The abstract service primitive from a Message Processing Model to a 1117 Security Model to generate the components of a Request message is 1118 generateRequestMsg(). 1120 The abstract service primitive from a Message Processing Model to a 1121 Security Model to generate the components of a Response message is 1122 generateResponseMsg(). 1124 Upon completion of processing, the Security Model returns 1125 statusInformation. If the process was successful, the completed 1126 message is returned. If the process was not successful, then an 1127 errorIndication is returned. 1129 The OUT parameters of the prepareOutgoingMessage() ASI are used to 1130 pass information from the message processing model to the dispatcher 1131 and on to the transport model: 1133 5.2. Processing for an Outgoing Message 1135 The sendMessage ASI is used to pass a message from the Dispatcher to 1136 the appropriate transport model for sending. 1138 statusInformation = 1139 sendMessage( 1140 IN destTransportDomain -- transport domain to be used 1141 IN destTransportAddress -- transport address to be used 1142 IN outgoingMessage -- the message to send 1143 IN outgoingMessageLength -- its length 1144 IN tmStateReference 1145 ) 1147 The Transport Subsystem provides the following primitives to pass 1148 data back and forth between the dispatcher and specific transport 1149 models, which provide the interface to the underlying secure 1150 transport service. Each transport model should define the elements 1151 of procedure for the openSession() and closeSession() interfaces. 1153 statusInformation = 1154 openSession( 1155 IN transportDomain -- transport domain to be used 1156 IN transportAddress -- transport address to be used 1157 IN tmStateReference 1158 ) 1160 statusInformation = 1161 closeSession( 1162 IN tmStateReference 1163 ) 1165 5.3. Processing an Incoming SNMP Message 1167 5.3.1. Processing an Incoming Message 1169 If one does not exist, the Transport Model will need to create an 1170 entry in a Local Configuration Datastore referenced by 1171 tmStateReference. This information will include transportDomain, 1172 transportAddress, the securityModel, the securityLevel, and the 1173 securityName, plus any model or mechanism-specific details. How this 1174 information is determined is model-specific. 1176 The recvMessage ASI is used to pass a message from the transport 1177 subsystem to the Dispatcher. 1179 statusInformation = 1180 recvMessage( 1181 IN destTransportDomain -- transport domain to be used 1182 IN destTransportAddress -- transport address to be used 1183 IN incomingMessage -- the message received 1184 IN incomingMessageLength -- its length 1185 IN tmStateReference 1186 ) 1188 5.3.2. Prepare Data Elements from Incoming Messages 1190 The abstract service primitive from the Dispatcher to a Message 1191 Processing Model for a received message is: 1193 result = -- SUCCESS or errorIndication 1194 prepareDataElements( 1195 IN transportDomain -- origin transport domain 1196 IN transportAddress -- origin transport address 1197 IN wholeMsg -- as received from the network 1198 IN wholeMsgLength -- as received from the network 1199 IN tmStateReference -- from the transport model 1200 OUT messageProcessingModel -- typically, SNMP version 1201 OUT securityModel -- Security Model to use 1202 OUT securityName -- on behalf of this principal 1203 OUT securityLevel -- Level of Security requested 1204 OUT contextEngineID -- data from/at this entity 1205 OUT contextName -- data from/in this context 1206 OUT pduVersion -- the version of the PDU 1207 OUT PDU -- SNMP Protocol Data Unit 1208 OUT pduType -- SNMP PDU type 1209 OUT sendPduHandle -- handle for matched request 1210 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1211 OUT statusInformation -- success or errorIndication 1212 -- error counter OID/value if error 1213 OUT stateReference -- reference to state information 1214 -- to be used for possible Response 1215 ) 1217 Note that tmStateReference has been added to this ASI. 1219 5.3.3. Processing an Incoming Message 1221 This section describes the procedure followed by the Security Model 1222 whenever it receives an incoming message containing a management 1223 operation on behalf of a user from a Message Processing model. 1225 The Message Processing Model extracts some information from the 1226 wholeMsg. The abstract service primitive from a Message Processing 1227 Model to the Security Subsystem for a received message is:: 1229 statusInformation = -- errorIndication or success 1230 -- error counter OID/value if error 1231 processIncomingMsg( 1232 IN messageProcessingModel -- typically, SNMP version 1233 IN maxMessageSize -- of the sending SNMP entity 1234 IN securityParameters -- for the received message 1235 IN securityModel -- for the received message 1236 IN securityLevel -- Level of Security 1237 IN wholeMsg -- as received on the wire 1238 IN wholeMsgLength -- length as received on the wire 1239 IN tmStateReference -- from the transport model 1240 OUT securityEngineID -- authoritative SNMP entity 1241 OUT securityName -- identification of the principal 1242 OUT scopedPDU, -- message (plaintext) payload 1243 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1244 OUT securityStateReference -- reference to security state 1245 ) -- information, needed for response 1247 1) The securityEngineID is set to a value in a model-specific manner. 1248 If the securityEngineID is not utilized by the specific model, then 1249 it should be set to the local snmpEngineID, to satisfy the SNMPv3 1250 message processing model in RFC 3412 section 7.2 13a). 1252 2) Extract the value of securityName from the Local Configuration 1253 Datastore entry referenced by tmStateReference. 1255 3) The scopedPDU component is extracted from the wholeMsg. 1257 4) The maxSizeResponseScopedPDU is calculated. This is the maximum 1258 size allowed for a scopedPDU for a possible Response message. 1260 5)The security data is cached as cachedSecurityData, so that a 1261 possible response to this message can and will use the same security 1262 parameters. Then securityStateReference is set for subsequent 1263 reference to this cached data. 1265 4) The statusInformation is set to success and a return is made to 1266 the calling module passing back the OUT parameters as specified in 1267 the processIncomingMsg primitive. 1269 6. The Transport-Subsystem-MIB Module 1271 This memo defines a portion of the Management Information Base (MIB) 1272 for statistics in the Transport Subsystem. 1274 6.1. Structure of the MIB Module 1276 Objects in this MIB module are arranged into subtrees. Each subtree 1277 is organized as a set of related objects. The overall structure and 1278 assignment of objects to their subtrees, and the intended purpose of 1279 each subtree, is shown below. 1281 6.1.1. The tmsmStats Subtree 1283 This subtree contains security-model-independent counters which are 1284 applicable to all security models based on the .Transport Subsystem. 1285 This subtree provides information for identifying fault conditions 1286 and performance degradation. 1288 6.2. Relationship to Other MIB Modules 1290 Some management objects defined in other MIB modules are applicable 1291 to an entity implementing this MIB. In particular, it is assumed 1292 that an entity implementing the Transport-Subsystem-MIB module will 1293 also implement the SNMPv2-MIB [RFC3418]. 1295 This MIB module is expected to be used with the MIB modules defined 1296 for managing specific transport models within the transport 1297 subsystem. This MIB module is designed to be transport-model 1298 independent and security-model independent, and contains objects 1299 useful for managing common aspects of any transport model. Specific 1300 transport models may define a MIB module to contain transport-model 1301 dependent information. 1303 6.2.1. Textual Conventions 1305 Generic and Common Textual Conventions used in this document can be 1306 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1308 6.2.2. MIB Modules Required for IMPORTS 1310 The. following MIB module imports items from [RFC2578], [RFC2579], 1311 [RFC2580], [RFC3411], and [RFC3419] 1313 6.3. Definitions 1315 Transport-Subsystem-MIB DEFINITIONS ::= BEGIN 1317 IMPORTS 1318 MODULE-IDENTITY, OBJECT-TYPE, 1319 mib-2, Integer32, Unsigned32, Gauge32 1320 FROM SNMPv2-SMI 1321 TestAndIncr, StorageType, RowStatus 1322 FROM SNMPv2-TC 1323 MODULE-COMPLIANCE, OBJECT-GROUP 1324 FROM SNMPv2-CONF 1325 SnmpSecurityModel, 1326 SnmpAdminString, SnmpSecurityLevel, SnmpEngineID 1327 FROM SNMP-FRAMEWORK-MIB 1328 TransportAddress, TransportAddressType 1329 FROM TRANSPORT-ADDRESS-MIB 1330 ; 1332 tmsMIB MODULE-IDENTITY 1333 LAST-UPDATED "200610060000Z" 1334 ORGANIZATION "ISMS Working Group" 1335 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1336 Subscribe: isms-request@lists.ietf.org 1338 Chairs: 1339 Juergen Quittek 1340 NEC Europe Ltd. 1341 Network Laboratories 1342 Kurfuersten-Anlage 36 1343 69115 Heidelberg 1344 Germany 1345 +49 6221 90511-15 1346 quittek@netlab.nec.de 1348 Juergen Schoenwaelder 1349 International University Bremen 1350 Campus Ring 1 1351 28725 Bremen 1352 Germany 1353 +49 421 200-3587 1354 j.schoenwaelder@iu-bremen.de 1356 Editor: 1357 David Harrington 1358 FutureWei Technologies 1359 1700 Alma Drive, Suite 100 1360 Plano, Texas 75075 1361 USA 1362 +1 603-436-8634 1363 dharrington@huawei.com 1364 " 1365 DESCRIPTION "The Transport Subsystem MIB Module 1367 Copyright (C) The Internet Society (2006). This 1368 version of this MIB module is part of RFC XXXX; 1369 see the RFC itself for full legal notices. 1371 -- NOTE to RFC editor: replace XXXX with actual RFC number 1372 -- for this document and remove this note 1373 " 1375 REVISION "200610060000Z" -- 20 April 2006 1376 DESCRIPTION "The initial version, published in RFC XXXX. 1377 -- NOTE to RFC editor: replace XXXX with actual RFC number 1378 -- for this document and remove this note 1379 " 1381 ::= { mib-2 xxxx } 1382 -- RFC Ed.: replace xxxx with IANA-assigned number and 1383 -- remove this note 1385 -- ---------------------------------------------------------- -- 1386 -- subtrees in the Transport-Subsystem-MIB 1387 -- ---------------------------------------------------------- -- 1389 tmsNotifications OBJECT IDENTIFIER ::= { tmsMIB 0 } 1390 tmsObjects OBJECT IDENTIFIER ::= { tmsMIB 1 } 1391 tmsConformance OBJECT IDENTIFIER ::= { tmsMIB 2 } 1393 -- ------------------------------------------------------------- 1394 -- Objects 1395 -- ------------------------------------------------------------- 1397 -- Textual Conventions 1399 SnmpTransportModel ::= TEXTUAL-CONVENTION 1400 STATUS current 1401 DESCRIPTION "An identifier that uniquely identifies a 1402 Transport Model of the Transport Subsystem within 1403 the SNMP Management Architecture. 1405 The values for transportModel are allocated as 1406 follows: 1408 - The zero value does not identify any particular 1409 transport model. 1411 - Values between 1 and 255, inclusive, are reserved 1412 for standards-track Transport Models and are 1413 managed by the Internet Assigned Numbers Authority 1414 (IANA). 1415 - Values greater than 255 are allocated to 1416 enterprise-specific Transport Models. An 1417 enterprise-specific transportModel value is defined 1418 to be: 1420 enterpriseID * 256 + transport model within 1421 enterprise 1423 For example, the fourth Transport Model defined by 1424 the enterprise whose enterpriseID is 1 would be 1425 260. 1427 This scheme for allocation of transportModel 1428 values allows for a maximum of 255 standards- 1429 based Transport Models, and for a maximum of 1430 256 Transport Models per enterprise. 1432 It is believed that the assignment of new 1433 transportModel values will be rare in practice 1434 because the larger the number of simultaneously 1435 utilized Transport Models, the larger the 1436 chance that interoperability will suffer. 1437 Consequently, it is believed that such a range 1438 will be sufficient. In the unlikely event that 1439 the standards committee finds this number to be 1440 insufficient over time, an enterprise number 1441 can be allocated to obtain an additional 256 1442 possible values. 1444 Note that the most significant bit must be zero; 1445 hence, there are 23 bits allocated for various 1446 organizations to design and define non-standard 1447 transportModels. This limits the ability to 1448 define new proprietary implementations of Transport 1449 Models to the first 8,388,608 enterprises. 1451 It is worthwhile to note that, in its encoded 1452 form, the transportModel value will normally 1453 require only a single byte since, in practice, 1454 the leftmost bits will be zero for most messages 1455 and sign extension is suppressed by the encoding 1456 rules. 1458 As of this writing, there are several values 1459 of transportModel defined for use with SNMP or 1460 reserved for use with supporting MIB objects. 1461 They are as follows: 1463 0 reserved for 'any' 1464 1 reserved for UDP 1465 2 reserved for TCP 1466 3 SSH Transport Model 1467 " 1469 SYNTAX INTEGER(0 .. 2147483647) 1471 -- Notifications for the Transport Subsystem 1473 -- Statistics for the Transport Subsystem 1475 tmsStats OBJECT IDENTIFIER ::= { tmsObjects 1 } 1477 -- ------------------------------------------------------------- 1478 -- Conformance Information 1479 -- ------------------------------------------------------------- 1481 tmsGroups OBJECT IDENTIFIER ::= { tmsConformance 1 } 1483 tmsCompliances OBJECT IDENTIFIER ::= { tmsConformance 2 } 1485 -- ------------------------------------------------------------- 1486 -- Units of conformance 1487 -- ------------------------------------------------------------- 1488 tmsGroup OBJECT-GROUP 1489 OBJECTS { 1491 } 1492 STATUS current 1493 DESCRIPTION "A collection of objects for maintaining session 1494 information of an SNMP engine which implements the 1495 Transport subsystem. 1496 " 1498 ::= { tmsGroups 2 } 1500 -- ------------------------------------------------------------- 1501 -- Compliance statements 1502 -- ------------------------------------------------------------- 1504 tmsCompliance MODULE-COMPLIANCE 1505 STATUS current 1506 DESCRIPTION 1507 "The compliance statement for SNMP engines that support the 1508 Transport-Subsystem-MIB" 1509 MODULE 1510 MANDATORY-GROUPS { tmsGroup } 1511 ::= { tmsCompliances 1 } 1513 END 1515 7. Security Considerations 1517 This document describes an architectural approach and multiple 1518 proposed configurations that would permit SNMP to utilize transport 1519 layer security services. Each section containing a proposal should 1520 discuss the security considerations. 1522 It is considered desirable by some industry segments that SNMP 1523 transport models should utilize transport layer security that 1524 addresses perfect forward secrecy at least for encryption keys. 1525 Perfect forward secrecy guarantees that compromise of long term 1526 secret keys does not result in disclosure of past session keys. 1528 There are no management objects defined in this MIB module that have 1529 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1530 MIB module is implemented correctly, then there is no risk that an 1531 intruder can alter or create any management objects of this MIB 1532 module via direct SNMP SET operations. 1534 Some of the readable objects in this MIB module (i.e., objects with a 1535 MAX-ACCESS other than not-accessible) may be considered sensitive or 1536 vulnerable in some network environments. It is thus important to 1537 control even GET and/or NOTIFY access to these objects and possibly 1538 to even encrypt the values of these objects when sending them over 1539 the network via SNMP. These are the tables and objects and their 1540 sensitivity/vulnerability: 1541 o [todo] list the tables and objects and state why they are 1542 sensitive. 1544 SNMP versions prior to SNMPv3 did not include adequate security. 1545 Even if the network itself is secure (for example by using IPSec), 1546 even then, there is no control as to who on the secure network is 1547 allowed to access and GET/SET (read/change/create/delete) the objects 1548 in this MIB module. 1550 It is RECOMMENDED that implementers consider the security features as 1551 provided by the SNMPv3 framework (see [RFC3410], section 8), 1552 including full support for the SNMPv3 cryptographic mechanisms (for 1553 authentication and privacy). 1555 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1556 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1557 enable cryptographic security. It is then a customer/operator 1558 responsibility to ensure that the SNMP entity giving access to an 1559 instance of this MIB module is properly configured to give access to 1560 the objects only to those principals (users) that have legitimate 1561 rights to indeed GET or SET (change/create/delete) them. 1563 8. IANA Considerations 1565 IANA is requested to create a new registry in the Simple Network 1566 Management Protocol (SNMP) Number Spaces for SnmpTransportModels, as 1567 described in the Transport-Subsystem-MIB defined in this document. 1568 Values 0 through 255 are IANA-assigned by Standards Action, as 1569 defined in RFC2434. Values above 255 are assigned by Hierarchical 1570 allocation, using the algorithm defined in the definition of the 1571 SnmpTransportModels TEXTUAL-CONVENTION in the Transport-Subsystem-MIB 1572 in this document. 1574 The MIB module in this document uses the following IANA-assigned 1575 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1577 Descriptor OBJECT IDENTIFIER value 1578 ---------- ----------------------- 1580 Transport-Subsystem-MIB { mib-2 XXXX } 1582 Editor's Note (to be removed prior to publication): the IANA is 1583 requested to assign a value for "XXXX" under the 'mib-2' subtree 1584 and to record the assignment in the SMI Numbers registry. When 1585 the assignment has been made, the RFC Editor is asked to replace 1586 "XXXX" (here and in the MIB module) with the assigned value and to 1587 remove this note. 1589 9. Acknowledgments 1591 The Integrated Security for SNMP WG would like to thank the following 1592 people for their contributions to the process: 1594 The authors of submitted security model proposals: Chris Elliot, Wes 1595 Hardaker, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave 1596 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1598 The members of the Protocol Evaluation Team: Uri Blumenthal, 1599 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1601 WG members who committed to and performed detailed reviews: Jeffrey 1602 Hutzelman 1604 10. References 1605 10.1. Normative References 1607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1608 Requirement Levels", BCP 14, RFC 2119, March 1997. 1610 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1611 and T. Wright, "Transport Layer Security (TLS) 1612 Extensions", RFC 4366, April 2006. 1614 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1615 Schoenwaelder, Ed., "Structure of Management Information 1616 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1618 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1619 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1620 STD 58, RFC 2579, April 1999. 1622 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1623 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1624 April 1999. 1626 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1627 "Remote Authentication Dial In User Service (RADIUS)", 1628 RFC 2865, June 2000. 1630 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1631 Architecture for Describing Simple Network Management 1632 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1633 December 2002. 1635 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1636 "Message Processing and Dispatching for the Simple Network 1637 Management Protocol (SNMP)", STD 62, RFC 3412, 1638 December 2002. 1640 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1641 (USM) for version 3 of the Simple Network Management 1642 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1644 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1645 Simple Network Management Protocol (SNMP)", STD 62, 1646 RFC 3416, December 2002. 1648 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1649 Management Protocol (SNMP)", STD 62, RFC 3417, 1650 December 2002. 1652 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1653 Simple Network Management Protocol (SNMP)", STD 62, 1654 RFC 3418, December 2002. 1656 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 1657 Transport Addresses", RFC 3419, December 2002. 1659 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1660 Protocol Architecture", RFC 4251, January 2006. 1662 10.2. Informative References 1664 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1665 Stewart, "Introduction and Applicability 1666 Statements for Internet-Standard Management 1667 Framework", RFC 3410, December 2002. 1669 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 1670 Network Management Protocol (SNMP) 1671 Applications", STD 62, RFC 3413, 1672 December 2002. 1674 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple 1675 Authentication and Security Layer (SASL)", 1676 RFC 4422, June 2006. 1678 [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the 1679 NETCONF Configuration Protocol over Secure 1680 Shell (SSH)", draft-ietf-netconf-ssh-06 (work 1681 in progress), March 2006. 1683 Appendix A. Parameter Table 1685 Following is a CSV formatted matrix useful for tracking data flows 1686 into and out of the dispatcher, message, and security subsystems. 1687 Import this into your favorite spreadsheet or other CSV compatible 1688 application. You will need to remove lines feeds from the second and 1689 third lines, which needed to be wrapped to fit into RFC limits. 1691 A.1. ParameterList.csv 1693 ,Dispatcher,,,,Messaging,,,Security,, 1695 ,sendPdu,returnResponse,processPdu,processResponse 1696 ,prepareOutgoingMessage,prepareResponseMessage,prepareDataElements 1697 ,generateRequest,processIncoming,generateResponse 1699 transportDomain,In,,,,In,,In,,, 1700 transportAddress,In,,,,In,,In,,, 1702 destTransportDomain,,,,,Out,Out,,,, 1704 destTransportAddress,,,,,Out,Out,,,, 1706 messageProcessingModel,In,In,In,In,In,In,Out,In,In,In 1708 securityModel,In,In,In,In,In,In,Out,In,In,In 1710 securityName,In,In,In,In,In,In,Out,In,Out,In 1712 securityLevel,In,In,In,In,In,In,Out,In,In,In 1714 contextEngineID,In,In,In,In,In,In,Out,,, 1716 contextName,In,In,In,In,In,In,Out,,, 1718 expectResponse,In,,,,In,,,,, 1720 PDU,In,In,In,In,In,In,Out,,, 1722 pduVersion,In,In,In,In,In,In,Out,,, 1724 statusInfo,Out,In,,In,,In,Out,Out,Out,Out 1726 errorIndication,Out,Out,,,,,Out,,, 1728 sendPduHandle,Out,,,In,In,,Out,,, 1730 maxSizeResponsePDU,,In,In,,,In,Out,,Out, 1732 stateReference,,In,In,,,In,Out,,, 1734 wholeMessage,,,,,Out,Out,,Out,In,Out 1736 messageLength,,,,,Out,Out,,Out,In,Out 1738 maxMessageSize,,,,,,,,In,In,In 1740 globalData,,,,,,,,In,,In 1742 securityEngineID,,,,,,,,In,Out,In 1744 scopedPDU,,,,,,,,In,Out,In 1746 securityParameters,,,,,,,,Out,,Out 1747 securityStateReference,,,,,,,,,Out,In 1749 pduType,,,,,,,Out,,, 1751 tmStateReference,,,,,,Out,In,,In, 1753 Appendix B. Why tmStateReference? 1755 This appendix considers why a cache-based approach was selected for 1756 passing parameters. This section may be removed from subsequent 1757 revisions of the document. 1759 There are four approaches that could be used for passing information 1760 between the Transport Model and an Security Model. 1762 1. one could define an ASI to supplement the existing ASIs, or 1763 2. one could add a header to encapsulate the SNMP message, 1764 3. one could utilize fields already defined in the existing SNMPv3 1765 message, or 1766 4. one could pass the information in an implementation-specific 1767 cache or via a MIB module. 1769 B.1. Define an Abstract Service Interface 1771 Abstract Service Interfaces (ASIs) [RFC3411] are defined by a set of 1772 primitives that specify the services provided and the abstract data 1773 elements that are to be passed when the services are invoked. 1774 Defining additional ASIs to pass the security and transport 1775 information from the transport subsystem to security subsystem has 1776 the advantage of being consistent with existing RFC3411/3412 1777 practice, and helps to ensure that any transport model proposals pass 1778 the necessary data, and do not cause side effects by creating model- 1779 specific dependencies between itself and other models or other 1780 subsystems other than those that are clearly defined by an ASI. 1782 B.2. Using an Encapsulating Header 1784 A header could encapsulate the SNMP message to pass necessary 1785 information from the Transport Model to the dispatcher and then to a 1786 messaging security model. The message header would be included in 1787 the wholeMessage ASI parameter, and would be removed by a 1788 corresponding messaging model. This would imply the (one and only) 1789 messaging dispatcher would need to be modified to determine which 1790 SNMP message version was involved, and a new message processing model 1791 would need to be developed that knew how to extract the header from 1792 the message and pass it to the Security Model. 1794 B.3. Modifying Existing Fields in an SNMP Message 1796 [RFC3412] describes the SNMPv3 message, which contains fields to pass 1797 security related parameters. The transport subsystem could use these 1798 fields in an SNMPv3 message, or comparable fields in other message 1799 formats to pass information between transport models in different 1800 SNMP engines, and to pass information between a transport model and a 1801 corresponding messaging security model. 1803 If the fields in an incoming SNMPv3 message are changed by the 1804 Transport Model before passing it to the Security Model, then the 1805 Transport Model will need to decode the ASN.1 message, modify the 1806 fields, and re-encode the message in ASN.1 before passing the message 1807 on to the message dispatcher or to the transport layer. This would 1808 require an intimate knowledge of the message format and message 1809 versions so the Transport Model knew which fields could be modified. 1810 This would seriously violate the modularity of the architecture. 1812 B.4. Using a Cache 1814 This document describes a cache, into which the Transport Model puts 1815 information about the security applied to an incoming message, and an 1816 Security Model extracts that information from the cache. Given that 1817 there may be multiple TM-security caches, a tmStateReference is 1818 passed as an extra parameter in the ASIs between the transport 1819 subsystem and the security subsystem, so the Security Model knows 1820 which cache of information to consult. 1822 This approach does create dependencies between a specific Transport 1823 Model and a corresponding specific Security Model. This approach of 1824 passing a model-independent reference is consistent with the 1825 securityStateReference cache already being passed around in the 1826 RFC3411 ASIs. 1828 Appendix C. Open Issues 1830 Appendix D. Change Log 1832 NOTE to RFC editor: Please remove this change log before publishing 1833 this document as an RFC. 1835 Changes from revision -03- to -04- 1837 changed title from Transport Mapping Security Model Architectural 1838 Extension to Transport Subsystem 1839 modified the abstract and introduction 1840 changed TMSM to TMS 1841 changed MPSP to simply Security Model 1842 changed SMSP to simply Security Model 1843 changed TMSP to Transport Model 1844 removed MPSP and TMSP and SMSP from Acronyms section 1845 modified diagrams 1846 removed most references to dispatcher functionality 1847 worked to remove dependencies between transport and security 1848 models. 1849 defined snmpTransportModel enumeration similar to 1850 snmpSecurityModel, etc. 1851 eliminated all reference to SNMPv3 msgXXXX fields 1852 changed tmSessionReference back to tmStateReference 1854 Changes from revision -02- to -03- 1856 o removed session table from MIB module 1857 o removed sessionID from ASIs 1858 o reorganized to put ASI discussions in EOP section, as was done in 1859 SSHSM 1860 o changed user auth to client auth 1861 o changed tmStateReference to tmSessionReference 1862 o modified document to meet consensus positions published by JS 1863 o 1864 * authoritative is model-specific 1865 * msgSecurityParameters usage is model-specific 1866 * msgFlags vs. securityLevel is model/implementation-specific 1867 * notifications must be able to cause creation of a session 1868 * security considerations must be model-specific 1869 * TDomain and TAddress are model-specific 1870 * MPSP changed to SMSP (Security model security processing) 1872 Changes from revision -01- to -02- 1874 o wrote text for session establishment requirements section. 1875 o wrote text for session maintenance requirements section. 1876 o removed section on relation to SNMPv2-MIB 1877 o updated MIB module to pass smilint 1878 o Added Structure of the MIB module, and other expected MIB-related 1879 sections. 1880 o updated author address 1881 o corrected spelling 1882 o removed msgFlags appendix 1883 o Removed section on implementation considerations. 1884 o started modifying the security boilerplate to address TMS and MIB 1885 security issues 1887 o reorganized slightly to better separate requirements from proposed 1888 solution. This probably needs additional work. 1889 o removed section with sample protocols and sample 1890 tmSessionReference. 1891 o Added section for acronyms 1892 o moved section comparing parameter passing techniques to appendix. 1893 o Removed section on notification requirements. 1895 Changes from revision -00- 1896 o changed SSH references from I-Ds to RFCs 1897 o removed parameters from tmSessionReference for DTLS that revealed 1898 lower layer info. 1899 o Added TMS-MIB module 1900 o Added Internet-Standard Management Framework boilerplate 1901 o Added Structure of the MIB Module 1902 o Added MIB security considerations boilerplate (to be completed) 1903 o Added IANA Considerations 1904 o Added ASI Parameter table 1905 o Added discussion of Sessions 1906 o Added Open issues and Change Log 1907 o Rearranged sections 1909 Authors' Addresses 1911 David Harrington 1912 Huawei Technologies (USA) 1913 1700 Alma Dr. Suite 100 1914 Plano, TX 75075 1915 USA 1917 Phone: +1 603 436 8634 1918 EMail: dharrington@huawei.com 1920 Juergen Schoenwaelder 1921 International University Bremen 1922 Campus Ring 1 1923 28725 Bremen 1924 Germany 1926 Phone: +49 421 200-3587 1927 EMail: j.schoenwaelder@iu-bremen.de 1929 Full Copyright Statement 1931 Copyright (C) The Internet Society (2006). 1933 This document is subject to the rights, licenses and restrictions 1934 contained in BCP 78, and except as set forth therein, the authors 1935 retain all their rights. 1937 This document and the information contained herein are provided on an 1938 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1939 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1940 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1941 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1942 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1945 Intellectual Property 1947 The IETF takes no position regarding the validity or scope of any 1948 Intellectual Property Rights or other rights that might be claimed to 1949 pertain to the implementation or use of the technology described in 1950 this document or the extent to which any license under such rights 1951 might or might not be available; nor does it represent that it has 1952 made any independent effort to identify any such rights. Information 1953 on the procedures with respect to rights in RFC documents can be 1954 found in BCP 78 and BCP 79. 1956 Copies of IPR disclosures made to the IETF Secretariat and any 1957 assurances of licenses to be made available, or the result of an 1958 attempt made to obtain a general license or permission for the use of 1959 such proprietary rights by implementers or users of this 1960 specification can be obtained from the IETF on-line IPR repository at 1961 http://www.ietf.org/ipr. 1963 The IETF invites any interested party to bring to its attention any 1964 copyrights, patents or patent applications, or other proprietary 1965 rights that may cover technology that may be required to implement 1966 this standard. Please address the information to the IETF at 1967 ietf-ipr@ietf.org. 1969 Acknowledgement 1971 Funding for the RFC Editor function is provided by the IETF 1972 Administrative Support Activity (IASA).