idnits 2.17.1 draft-ietf-isms-transport-security-model-10.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, updated by RFC 4748 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1583. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1246 has weird spacing: '...tyLevel auth...' == 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 (November 1, 2008) is 5627 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1103, but not defined == Unused Reference: 'RFC3414' is defined on line 1166, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Standards Track W. Hardaker 5 Expires: May 5, 2009 Sparta, Inc. 6 November 1, 2008 8 Transport Security Model for SNMP 9 draft-ietf-isms-transport-security-model-10 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 May 5, 2009. 36 Abstract 38 This memo describes a Transport Security Model for the Simple Network 39 Management Protocol. 41 This memo also defines a portion of the Management Information Base 42 (MIB) for monitoring and managing the Transport Security Model for 43 SNMP. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.1. The Internet-Standard Management Framework . . . . . . . . 4 49 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 52 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 53 2. How the Transport Security Model Fits in the Architecture . . 6 54 2.1. Security Capabilities of this Model . . . . . . . . . . . 7 55 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 57 2.2. Transport Sessions . . . . . . . . . . . . . . . . . . . . 8 58 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8 59 2.3.1. Coexistence with Message Processing Models . . . . . . 8 60 2.3.2. Coexistence with Other Security Models . . . . . . . . 8 61 2.3.3. Coexistence with Transport Models . . . . . . . . . . 9 62 3. Cached Information and References . . . . . . . . . . . . . . 9 63 3.1. securityStateReference . . . . . . . . . . . . . . . . . . 9 64 3.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 10 65 3.2.1. Transport information . . . . . . . . . . . . . . . . 10 66 3.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 11 67 3.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 11 68 3.2.4. Session Information . . . . . . . . . . . . . . . . . 12 69 3.3. Transport Security Model Cached Information . . . . . . . 12 70 3.3.1. securityStateReference . . . . . . . . . . . . . . . . 12 71 3.3.2. tmStateReference . . . . . . . . . . . . . . . . . . . 13 72 3.3.3. Prefixes and securityNames . . . . . . . . . . . . . . 13 73 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 13 74 4.1. Security Processing for an Outgoing Message . . . . . . . 14 75 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 15 76 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 16 77 5.1. Security Processing for an Incoming Message . . . . . . . 16 78 5.2. Elements of Procedure for Incoming Messages . . . . . . . 17 79 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 18 80 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 18 81 6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 18 82 6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 18 83 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 19 84 6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 19 85 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 19 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 87 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 24 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 93 Appendix A. Notification Tables Configuration . . . . . . . . . . 27 94 A.1. Transport Security Model Processing for Notifications . . 29 95 Appendix B. Processing Differences between USM and Secure 96 Transport . . . . . . . . . . . . . . . . . . . . . . 29 98 B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 30 99 B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 30 100 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 31 101 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 This memo describes a Transport Security Model for the Simple Network 106 Management Protocol, for use with secure Transport Models in the 107 Transport Subsystem [I-D.ietf-isms-tmsm]. 109 This memo also defines a portion of the Management Information Base 110 (MIB) for monitoring and managing the Transport Security Model for 111 SNMP. 113 It is important to understand the SNMP architecture and the 114 terminology of the architecture to understand where the Transport 115 Security Model described in this memo fits into the architecture and 116 interacts with other subsystems and models within the architecture. 117 It is expected that reader will have also read and understood RFC3411 118 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 119 [RFC3418]. 121 1.1. The Internet-Standard Management Framework 123 For a detailed overview of the documents that describe the current 124 Internet-Standard Management Framework, please refer to section 7 of 125 RFC 3410 [RFC3410]. 127 Managed objects are accessed via a virtual information store, termed 128 the Management Information Base or MIB. MIB objects are generally 129 accessed through the Simple Network Management Protocol (SNMP). 130 Objects in the MIB are defined using the mechanisms defined in the 131 Structure of Management Information (SMI). This memo specifies a MIB 132 module that is compliant to the SMIv2, which is described in STD 58, 133 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 134 [RFC2580]. 136 1.2. Conventions 138 For consistency with SNMP-related specifications, this document 139 favors terminology as defined in STD62 rather than favoring 140 terminology that is consistent with non-SNMP specifications that use 141 different variations of the same terminology. This is consistent 142 with the IESG decision to not require the SNMPv3 terminology be 143 modified to match the usage of other non-SNMP specifications when 144 SNMPv3 was advanced to Full Standard. 146 Authentication in this document typically refers to the English 147 meaning of "serving to prove the authenticity of" the message, not 148 data source authentication or peer identity authentication. 150 The terms "manager" and "agent" are not used in this document, 151 because in the RFC 3411 architecture, all SNMP entities have the 152 capability of acting as either manager or agent or both depending on 153 the SNMP applications included in the engine. Where distinction is 154 required, the application names of Command Generator, Command 155 Responder, Notification Originator, Notification Receiver, and Proxy 156 Forwarder are used. See "SNMP Applications" [RFC3413] for further 157 information. 159 While security protocols frequently refer to a user, the terminology 160 used in RFC3411 [RFC3411] and in this memo is "principal". A 161 principal is the "who" on whose behalf services are provided or 162 processing takes place. A principal can be, among other things, an 163 individual acting in a particular role; a set of individuals, with 164 each acting in a particular role; an application or a set of 165 applications, or a combination of these within an administrative 166 domain. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 1.3. Modularity 174 The reader is expected to have read and understood the description of 175 the SNMP architecture, as defined in [RFC3411], and the architecture 176 extension specified in "Transport Subsystem for the Simple Network 177 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 178 external "lower layer transport" protocols to provide message 179 security, tied into the SNMP architecture through the Transport 180 Subsystem. The Transport Security Model is designed to work with 181 such lower-layer secure Transport Models. 183 In keeping with the RFC 3411 design decisions to use self-contained 184 documents, this memo includes the elements of procedure plus 185 associated MIB objects which are needed for processing the Transport 186 Security Model for SNMP. These MIB objects SHOULD NOT be referenced 187 in other documents. This allows the Transport Security Model to be 188 designed and documented as independent and self-contained, having no 189 direct impact on other modules, and allowing this module to be 190 upgraded and supplemented as the need arises, and to move along the 191 standards track on different time-lines from other modules. 193 This modularity of specification is not meant to be interpreted as 194 imposing any specific requirements on implementation. 196 1.4. Motivation 198 This memo describes a Security Model to make use of Transport Models 199 that use lower layer secure transports and existing and commonly 200 deployed security infrastructures. This Security Model is designed 201 to meet the security and operational needs of network administrators, 202 maximize usability in operational environments to achieve high 203 deployment success and at the same time minimize implementation and 204 deployment costs to minimize the time until deployment is possible. 206 1.5. Constraints 208 The design of this SNMP Security Model is also influenced by the 209 following constraints: 211 1. In times of network stress, the security protocol and its 212 underlying security mechanisms SHOULD NOT depend solely upon the 213 ready availability of other network services (e.g., Network Time 214 Protocol (NTP) or Authentication, Authorization, and Accounting 215 (AAA) protocols). 217 2. When the network is not under stress, the Security Model and its 218 underlying security mechanisms MAY depend upon the ready 219 availability of other network services. 221 3. It may not be possible for the Security Model to determine when 222 the network is under stress. 224 4. A Security Model should require no changes to the SNMP 225 architecture. 227 5. A Security Model should require no changes to the underlying 228 security protocol. 230 2. How the Transport Security Model Fits in the Architecture 232 The Transport Security Model is designed to fit into the RFC3411 233 architecture as a Security Model in the Security Subsystem, and to 234 utilize the services of a secure Transport Model. 236 For incoming messages, a secure Transport Model will pass a 237 tmStateReference cache, described later. To maintain RFC3411 238 modularity, the Transport Model will not know which securityModel 239 will process the incoming message; the Message Processing Model will 240 determine this. If the Transport Security Model is used with a non- 241 secure Transport Model, then the cache will not exist or not be 242 populated with security parameters, which will cause the Transport 243 Security Model to return an error (see section 5.2) 244 The Transport Security Model will create the securityName and 245 securityLevel to be passed to applications, and verify that the 246 tmTransportSecurityLevel reported by the Transport Model is at least 247 as strong as the securityLevel requested by the Message Processing 248 Model. 250 For outgoing messages, the Transport Security Model will create a 251 tmStateReference cache (or use an existing one), and pass the 252 tmStateReference to the specified Transport Model. 254 2.1. Security Capabilities of this Model 256 2.1.1. Threats 258 The Transport Security Model is compatible with the RFC3411 259 architecture, and provides protection against the threats identified 260 by the RFC 3411 architecture. However, the Transport Security Model 261 does not provide security mechanisms such as authentication and 262 encryption itself, so it SHOULD always be used with a Transport Model 263 that provides appropriate security. Which threats are addressed and 264 how they are mitigated depends on the Transport Model. 266 2.1.2. Security Levels 268 The RFC 3411 architecture recognizes three levels of security: 270 - without authentication and without privacy (noAuthNoPriv) 272 - with authentication but without privacy (authNoPriv) 274 - with authentication and with privacy (authPriv) 276 The model-independent securityLevel parameter is used to request 277 specific levels of security for outgoing messages, and to assert that 278 specific levels of security were applied during the transport and 279 processing of incoming messages. 281 The transport layer algorithms used to provide security SHOULD NOT be 282 exposed to the Transport Security Model, as the Transport Security 283 Model has no mechanisms by which it can test whether an assertion 284 made by a Transport Model is accurate. 286 The Transport Security Model trusts that the underlying secure 287 transport connection has been properly configured to support security 288 characteristics at least as strong as reported in 289 tmTransportSecurityLevel. 291 2.2. Transport Sessions 293 The Transport Security Model does not work with transport sessions 294 directly. Instead the transport-related state is associated with a 295 unique combination of transportDomain, transportAddress, securityName 296 and securityLevel, and referenced via the tmStateReference parameter. 297 How and if this is mapped to a particular transport or channel is the 298 responsibility of the Transport Subsystem. 300 2.3. Coexistence 302 In the RFC3411 architecture, a Message Processing Model determines 303 which Security Model should be called. As of this writing, IANA has 304 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 305 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 306 SNMPv2c, and the User-based Security Model). 308 2.3.1. Coexistence with Message Processing Models 310 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 311 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security 312 Models. Since there is no mechanism defined in RFC3584 to select an 313 alternative Security Model, SNMPv1 and SNMPv2c messages cannot use 314 the Transport Security Model. Such messages can still be conveyed 315 over a secure transport protocol, but the Transport Security Model 316 will not be invoked. 318 The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact 319 for which there is no existing IETF specification. 321 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 322 the securityModel from the msgSecurityModel field of an incoming 323 SNMPv3Message. When this value is transportSecurityModel(YY), 324 security processing is directed to the Transport Security Model. For 325 an outgoing message to be secured using the Transport Security Model, 326 the application should specify a securityModel parameter value of 327 transportSecurityModel(YY) in the sendPdu ASI. 329 [-- NOTE to RFC editor: replace YY with actual IANA-assigned number, 330 and remove this note. ] 332 2.3.2. Coexistence with Other Security Models 334 The Transport Security Model uses its own MIB module for processing 335 to maintain independence from other Security Models. This allows the 336 Transport Security Model to coexist with other Security Models, such 337 as the User-based Security Model. 339 2.3.3. Coexistence with Transport Models 341 The Transport Security Model may work with multiple Transport Models, 342 but the RFC3411 application service interfaces (ASIs) do not carry a 343 value for the Transport Model. The MIB module defined in this memo 344 allows an administrator to configure whether or not TSM prepends a 345 transport model prefix to the securityName. This will allow SNMP 346 applications to consider transport model as a factor when making 347 decisions, such as access control, notification generation, and proxy 348 forwarding. 350 3. Cached Information and References 352 When performing SNMP processing, there are two levels of state 353 information that may need to be retained: the immediate state linking 354 a request-response pair, and potentially longer-term state relating 355 to transport and security. 357 The RFC3411 architecture uses caches to maintain the short-term 358 message state, and uses references in the ASIs to pass this 359 information between subsystems. 361 This document defines the requirements for a cache to handle the 362 longer-term transport state information, using a tmStateReference 363 parameter to pass this information between subsystems. 365 To simplify the elements of procedure, the release of state 366 information is not always explicitly specified. As a general rule, 367 if state information is available when a message being processed gets 368 discarded, the state related to that message SHOULD also be 369 discarded. If state information is available when a relationship 370 between engines is severed, such as the closing of a transport 371 session, the state information for that relationship SHOULD also be 372 discarded. 374 Since the contents of a cache are meaningful only within an 375 implementation, and not on-the-wire, the format of the cache is 376 implementation-specific. 378 3.1. securityStateReference 380 The securityStateReference parameter is defined in RFC3411. Its 381 primary purpose is to provide a mapping between a request and the 382 corresponding response. This cache is not accessible to Transport 383 Models, and an entry is typically only retained for the lifetime of a 384 request-response pair of messages. 386 3.2. tmStateReference 388 For each transport session, information about the transport security 389 is stored in a cache. The tmStateReference parameter is used to pass 390 model-specific and mechanism-specific parameters between the 391 Transport subsystem and transport-aware Security Models. 393 The tmStateReference cache will typically remain valid for the 394 duration of the transport session, and hence may be used for several 395 messages. 397 Since this cache is only used within an implementation, and not on- 398 the-wire, the precise contents and format are implementation- 399 dependent. However, for interoperability between Transport Models 400 and transport-aware Security Models, entries in this cache must 401 include at least the following fields: 403 transportDomain 405 transportAddress 407 tmSecurityName 409 tmRequestedSecurityLevel 411 tmTransportSecurityLevel 413 tmSameSecurity 415 tmSessionID 417 3.2.1. Transport information 419 Information about the source of an incoming SNMP message is passed up 420 from the Transport subsystem as far as the Message Processing 421 subsystem. However these parameters are not included in the 422 processIncomingMsg ASI defined in RFC3411, and hence this information 423 is not directly available to the Security Model. 425 A transport-aware Security Model might wish to take account of the 426 transport protocol and originating address when authenticating the 427 request, and setting up the authorization parameters. It is 428 therefore necessary for the Transport Model to include this 429 information in the tmStateReference cache, so that it is accessible 430 to the Security Model. 432 o transportDomain: the transport protocol (and hence the Transport 433 Model) used to receive the incoming message 435 o transportAddress: the source of the incoming message. 437 The ASIs used for processing an outgoing message all include explicit 438 transportDomain and transportAddress parameters. The values within 439 the securityStateReference cache might override these parameters for 440 outgoing messages. 442 3.2.2. securityName 444 There are actually three distinct "identities" that can be identified 445 during the processing of an SNMP request over a secure transport: 447 o transport principal: the transport-authenticated identity, on 448 whose behalf the secure transport connection was (or should be) 449 established. This value is transport-, mechanism- and 450 implementation- specific, and is only used within a given 451 Transport Model. 453 o tmSecurityName: a human-readable name (in snmpAdminString format) 454 representing this transport identity. This value is transport- 455 and implementation-specific, and is only used (directly) by the 456 Transport and Security Models. 458 o securityName: a human-readable name (in snmpAdminString format) 459 representing the SNMP principal in a model-independent manner. 461 The transport principal may or may not be the same as the 462 tmSecurityName. Similarly, the tmSecurityName may or may not be the 463 same as the securityName as seen by the Application and Access 464 Control subsystems. In particular, a non-transport-aware Security 465 Model will ignore tmSecurityName completely when determining the SNMP 466 securityName. 468 However it is important that the mapping between the transport 469 principal and the SNMP securityName (for transport-aware Security 470 Models) is consistent and predictable, to allow configuration of 471 suitable access control and the establishment of transport 472 connections. 474 3.2.3. securityLevel 476 There are two distinct issues relating to security level as applied 477 to secure transports. For clarity, these are handled by separate 478 fields in the tmStateReference cache: 480 o tmTransportSecurityLevel: an indication from the Transport Model 481 of the level of security offered by this session. The Security 482 Model can use this to ensure that incoming messages were suitably 483 protected before acting on them. 485 o tmRequestedSecurityLevel: an indication from the Security Model of 486 the level of security required to be provided by the transport 487 protocol. The Transport Model can use this to ensure that 488 outgoing messages will not be sent over an insufficiently secure 489 session. 491 3.2.4. Session Information 493 For security reasons, if a secure transport session is closed between 494 the time a request message is received and the corresponding response 495 message is sent, then the response message SHOULD be discarded, even 496 if a new session has been established. The SNMPv3 WG decided that 497 this should be a SHOULD architecturally, and it is a security-model- 498 specific decision whether to REQUIRE this. 500 o tmSameSecurity: this flag is used by a transport-aware Security 501 Model to indicate whether the Transport Model MUST enforce this 502 restriction. 504 o tmSessionID: in order to verify whether the session has changed, 505 the Transport Model must be able to compare the session used to 506 receive the original request with the one to be used to send the 507 response. This typically requires some form of session 508 identifier. This value is only ever used by the Transport Model, 509 so the format and interpretation of this field are model-specific 510 and implementation-dependent. 512 When processing an outgoing message, if tmSameSecurity is true, then 513 the tmSessionID MUST match the current transport session, otherwise 514 the message MUST be discarded, and the dispatcher notified that 515 sending the message failed. 517 3.3. Transport Security Model Cached Information 519 The Transport Security Model has specific responsibilities regarding 520 the cached information. 522 3.3.1. securityStateReference 524 The Transport Security Model adds the tmStateReference received from 525 the processIncomingMsg ASI to the securityStateReference. This 526 tmStateReference can then be retrieved during the generateResponseMsg 527 ASI, so that it can be passed back to the Transport Model. 529 The Transport Security Model REQUIRES that the security parameters 530 used for a response are the same as those used for the corresponding 531 request. This security model sets the tmSameSecurity flag to true in 532 the tmStateReference before passing it to the transport model. 534 3.3.2. tmStateReference 536 For outgoing messages, the Transport Security Model uses parameters 537 provided by the SNMP application to lookup or create a 538 tmStateReference. This security model uses the tmStateReference 539 stored as part of the securityStateReference when appropriate. 541 For incoming messages, the Transport Security Model uses parameters 542 provided in the tmStateReference cache to determine the securityName, 543 and to verify adequate security levels. 545 3.3.3. Prefixes and securityNames 547 The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module 548 [RFC3413], and other MIB modules contain objects to configure 549 security parameters for use by applications such as access control, 550 notification generation, and proxy forwarding. 552 IANA maintains a registry for transport domains and the corresponding 553 prefix. 555 If snmpTsmConfigurationUsePrefix is set to true then all 556 securityNames provided by, or provided to, the Transport Security 557 Model MUST include a valid transport domain prefix. 559 If snmpTsmConfigurationUsePrefix is set to false then all 560 securityNames provided by, or provided to, the Transport Security 561 Model MUST NOT include a transport domain prefix. 563 The tmSecurityName in the tmStateReference stored as part of the 564 securityStateReference does not contain a prefix. 566 4. Processing an Outgoing Message 568 An error indication may return an OID and value for an incremented 569 counter and a value for securityLevel, and values for contextEngineID 570 and contextName for the counter, and the securityStateReference if 571 the information is available at the point where the error is 572 detected. 574 4.1. Security Processing for an Outgoing Message 576 This section describes the procedure followed by the Transport 577 Security Model. 579 The parameters needed for generating a message are supplied to the 580 Security Model by the Message Processing Model via the 581 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 582 Subsystem architectural extension has added the transportDomain, 583 transportAddress, and tmStateReference parameters to the original 584 RFC3411 ASIs. 586 statusInformation = -- success or errorIndication 587 generateRequestMsg( 588 IN messageProcessingModel -- typically, SNMP version 589 IN globalData -- message header, admin data 590 IN maxMessageSize -- of the sending SNMP entity 591 IN transportDomain -- (NEW) specified by application 592 IN transportAddress -- (NEW) specified by application 593 IN securityModel -- for the outgoing message 594 IN securityEngineID -- authoritative SNMP entity 595 IN securityName -- on behalf of this principal 596 IN securityLevel -- Level of Security requested 597 IN scopedPDU -- message (plaintext) payload 598 OUT securityParameters -- filled in by Security Module 599 OUT wholeMsg -- complete generated message 600 OUT wholeMsgLength -- length of generated message 601 OUT tmStateReference -- (NEW) transport info 602 ) 604 statusInformation = -- success or errorIndication 605 generateResponseMsg( 606 IN messageProcessingModel -- typically, SNMP version 607 IN globalData -- message header, admin data 608 IN maxMessageSize -- of the sending SNMP entity 609 IN transportDomain -- (NEW) specified by application 610 IN transportAddress -- (NEW) specified by application 611 IN securityModel -- for the outgoing message 612 IN securityEngineID -- authoritative SNMP entity 613 IN securityName -- on behalf of this principal 614 IN securityLevel -- Level of Security requested 615 IN scopedPDU -- message (plaintext) payload 616 IN securityStateReference -- reference to security state 617 -- information from original 618 -- request 619 OUT securityParameters -- filled in by Security Module 620 OUT wholeMsg -- complete generated message 621 OUT wholeMsgLength -- length of generated message 622 OUT tmStateReference -- (NEW) transport info 623 ) 625 4.2. Elements of Procedure for Outgoing Messages 627 1) If there is a securityStateReference (Response or Report message), 628 then this security model uses the cached information rather than the 629 information provided by the ASI. Extract the securityName and 630 securityLevel and tmStateReference from the securityStateReference 631 cache. Set the tmRequestedSecurityLevel to the value of the 632 extracted securityLevel. Set the tmSameSecurity parameter in the 633 tmStateReference cache to true. The cachedSecurityData for this 634 message can now be discarded. 636 2) If there is no securityStateReference then create a 637 tmStateReference cache with tmRequestedSecurityLevel set to the value 638 of securityLevel, the tmSecurityName set to securityName, and 639 tmSameSecurity set to false. 641 If the snmpTsmConfigurationUsePrefix object is set to true, then use 642 the transportDomain to look up the corresponding prefix. (Since the 643 securityStateReference stores the tmStateReference with the 644 unprefixed tmSecurityName for the incoming message, prefix stripping 645 only occurs when we are not using the securityStateReference). 647 a. If the prefix lookup fails for any reason, then the 648 snmpTsmUnknownPrefixes counter is incremented, an error 649 indication is returned to the calling module, and message 650 processing stops. 652 If the lookup succeeds, but the prefix returned does not match 653 the prefix in the securityName, or there is no prefix in the 654 securityName, then the snmpTsmInvalidPrefixes counter is 655 incremented, an error indication is returned to the calling 656 module, and message processing stops. 658 Strip the transport-specific prefix and trailing ':' character 659 (ASCII 0x3a) from the tmSecurityName. 661 3) Set securityParameters to a zero-length OCTET STRING ('0400'). 663 4) Combine the message parts into a wholeMsg and calculate 664 wholeMsgLength. 666 5) The wholeMsg, wholeMsgLength, securityParameters and 667 tmStateReference are returned to the calling Message Processing Model 668 with the statusInformation set to success. 670 5. Processing an Incoming SNMP Message 672 An error indication may return an OID and value for an incremented 673 counter and a value for securityLevel, and values for contextEngineID 674 and contextName for the counter, and the securityStateReference if 675 the information is available at the point where the error is 676 detected. 678 5.1. Security Processing for an Incoming Message 680 This section describes the procedure followed by the Transport 681 Security Model whenever it receives an incoming message from a 682 Message Processing Model. The ASI from a Message Processing Model to 683 the Security Subsystem for a received message is: 685 statusInformation = -- errorIndication or success 686 -- error counter OID/value if error 687 processIncomingMsg( 688 IN messageProcessingModel -- typically, SNMP version 689 IN maxMessageSize -- from the received message 690 IN securityParameters -- from the received message 691 IN securityModel -- from the received message 692 IN securityLevel -- from the received message 693 IN wholeMsg -- as received on the wire 694 IN wholeMsgLength -- length as received on the wire 695 IN tmStateReference -- (NEW) from the Transport Model 696 OUT securityEngineID -- authoritative SNMP entity 697 OUT securityName -- identification of the principal 698 OUT scopedPDU, -- message (plaintext) payload 699 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 700 OUT securityStateReference -- reference to security state 701 ) -- information, needed for response 703 5.2. Elements of Procedure for Incoming Messages 705 1) Set the securityEngineID to the local snmpEngineID. 707 2) If tmStateReference does not refer to a cache containing values 708 for transportDomain, transportAddress, tmSecurityName and 709 tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is 710 incremented, an error indication is returned to the calling module, 711 and Security Model processing stops for this message. 713 3) Copy the tmSecurityName to securityName. 715 If the snmpTsmConfigurationUsePrefix object is set to true, then use 716 the transportDomain to look up the corresponding prefix. 718 a. If the prefix lookup fails for any reason, then the 719 snmpTsmUnknownPrefixes counter is incremented and an error 720 indication is returned to the calling module, and message 721 processing stops. 723 If the lookup succeeds, but the prefix length is less than one or 724 greater than four octets, then the snmpTsmInvalidPrefixes counter 725 is incremented, an error indication is returned to the calling 726 module, and message processing stops. 728 Set the securityName to be the concatenation of the prefix, a ':' 729 character (ASCII 0x3a) and the tmSecurityName. 731 4) Compare the value of tmTransportSecurityLevel in the 732 tmStateReference cache to the value of the securityLevel parameter 733 passed in the processIncomingMsg ASI. If securityLevel specifies 734 privacy (Priv), and tmTransportSecurityLevel specifies no privacy 735 (noPriv), or securityLevel specifies authentication (auth) and 736 tmTransportSecurityLevel specifies no authentication (noAuth) was 737 provided by the Transport Model, then the 738 snmpTsmInadequateSecurityLevels counter is incremented, and an error 739 indication (unsupportedSecurityLevel) together with the OID and value 740 of the incremented counter is returned to the calling module. 741 Transport Security Model processing stops for this message. 743 5) The security data is cached as cachedSecurityData, so that a 744 possible response to this message will use the same security 745 parameters. Then securityStateReference is set for subsequent 746 reference to this cached data. For Transport Security Model, the 747 securityStateReference includes a reference to the tmStateReference 748 cache. 750 6) The scopedPDU component is extracted from the wholeMsg. 752 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 753 size allowed for a scopedPDU for a possible Response message. 755 8) The statusInformation is set to success and a return is made to 756 the calling module passing back the OUT parameters as specified in 757 the processIncomingMsg ASI. 759 6. MIB Module Overview 761 This MIB module provides objects for use only by the Transport 762 Security Model. It defines a configuration scalar and related error 763 counters. 765 6.1. Structure of the MIB Module 767 Objects in this MIB module are arranged into subtrees. Each subtree 768 is organized as a set of related objects. The overall structure and 769 assignment of objects to their subtrees, and the intended purpose of 770 each subtree, is shown below. 772 6.1.1. The snmpTsmStats Subtree 774 This subtree contains error counters specific to the Transport 775 Security Model. 777 6.1.2. The snmpTsmConfiguration Subtree 779 This subtree contains a configuration object that enables 780 administrators to specify if they want a transport domain prefix 781 prepended to securityNames for use by applications. 783 6.2. Relationship to Other MIB Modules 785 Some management objects defined in other MIB modules are applicable 786 to an entity implementing the Transport Security Model. In 787 particular, it is assumed that an entity implementing the Transport 788 Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the 789 SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and 790 the SNMPv2-MIB [RFC3418]. These are not needed to implement the 791 SNMP-TSM-MIB. 793 6.2.1. MIB Modules Required for IMPORTS 795 The following MIB module imports items from [RFC2578], [RFC2579], and 796 [RFC2580]. 798 7. MIB module definition 800 SNMP-TSM-MIB DEFINITIONS ::= BEGIN 802 IMPORTS 803 MODULE-IDENTITY, OBJECT-TYPE, 804 mib-2, Counter32 805 FROM SNMPv2-SMI 806 MODULE-COMPLIANCE, OBJECT-GROUP 807 FROM SNMPv2-CONF 808 TruthValue 809 FROM SNMPv2-TC 810 ; 812 snmpTsmMIB MODULE-IDENTITY 813 LAST-UPDATED "200807100000Z" 814 ORGANIZATION "ISMS Working Group" 815 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 816 Subscribe: isms-request@lists.ietf.org 818 Chairs: 819 Juergen Quittek 820 NEC Europe Ltd. 821 Network Laboratories 822 Kurfuersten-Anlage 36 823 69115 Heidelberg 824 Germany 825 +49 6221 90511-15 826 quittek@netlab.nec.de 827 Juergen Schoenwaelder 828 Jacobs University Bremen 829 Campus Ring 1 830 28725 Bremen 831 Germany 832 +49 421 200-3587 833 j.schoenwaelder@iu-bremen.de 835 Editor: 836 David Harrington 837 Huawei Technologies USA 838 1700 Alma Dr. 839 Plano TX 75075 840 USA 841 +1 603-436-8634 842 ietfdbh@comcast.net 844 Wes Hardaker 845 Sparta, Inc. 846 P.O. Box 382 847 Davis, CA 95617 848 USA 849 +1 530 792 1913 850 ietf@hardakers.net 851 " 852 DESCRIPTION "The Transport Security Model MIB 854 In keeping with the RFC 3411 design decisions 855 to use self-contained documents, the RFC which 856 contains the definition of this MIB module also 857 includes the elements of procedure which are 858 needed for processing the Transport Security 859 Model for SNMP. These MIB objects 860 SHOULD NOT be modified via other subsystems 861 or models defined in other document.. 862 This allows the Transport Security Model 863 for SNMP to be designed and documented as 864 independent and self- contained, having no 865 direct impact on other modules, and this 866 allows this module to be upgraded and 867 supplemented as the need arises, and to 868 move along the standards track on different 869 time-lines from other modules. 871 Copyright (C) The IETF Trust (2008). This 872 version of this MIB module is part of RFC XXXX; 873 see the RFC itself for full legal notices. 874 -- NOTE to RFC editor: replace XXXX with actual RFC number 875 -- for this document and remove this note 876 " 878 REVISION "200807100000Z" 879 DESCRIPTION "The initial version, published in RFC XXXX. 880 -- NOTE to RFC editor: replace XXXX with actual RFC number 881 -- for this document and remove this note 882 " 884 ::= { mib-2 xxxx } 885 -- RFC Ed.: replace xxxx with IANA-assigned number and 886 -- remove this note 888 -- ---------------------------------------------------------- -- 889 -- subtrees in the SNMP-TSM-MIB 890 -- ---------------------------------------------------------- -- 892 snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 } 893 snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 } 894 snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 } 896 -- ------------------------------------------------------------- 897 -- Objects 898 -- ------------------------------------------------------------- 900 -- Statistics for the Transport Security Model 902 snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 } 904 snmpTsmInvalidCaches OBJECT-TYPE 905 SYNTAX Counter32 906 MAX-ACCESS read-only 907 STATUS current 908 DESCRIPTION "The number of incoming messages dropped because the 909 tmStateReference referred to an invalid cache. 910 " 911 ::= { snmpTsmStats 1 } 913 snmpTsmInadequateSecurityLevels OBJECT-TYPE 914 SYNTAX Counter32 915 MAX-ACCESS read-only 916 STATUS current 917 DESCRIPTION "The number of incoming messages dropped because 918 the securityLevel asserted by the transport model was 919 less than the securityLevel requested by the 920 application. 921 " 923 ::= { snmpTsmStats 2 } 925 snmpTsmUnknownPrefixes OBJECT-TYPE 926 SYNTAX Counter32 927 MAX-ACCESS read-only 928 STATUS current 929 DESCRIPTION "The number of messages dropped because 930 snmpTsmConfigurationUsePrefix was set to true and 931 there is no known prefix for the specified transport 932 domain. 933 " 934 ::= { snmpTsmStats 3 } 936 snmpTsmInvalidPrefixes OBJECT-TYPE 937 SYNTAX Counter32 938 MAX-ACCESS read-only 939 STATUS current 940 DESCRIPTION "The number of messages dropped because 941 the securityName associated with an outgoing message 942 did not contain a valid transport domain prefix. 943 " 944 ::= { snmpTsmStats 4 } 946 -- ------------------------------------------------------------- 947 -- Configuration 948 -- ------------------------------------------------------------- 950 -- Configuration for the Transport Security Model 952 snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 } 954 snmpTsmConfigurationUsePrefix OBJECT-TYPE 955 SYNTAX TruthValue 956 MAX-ACCESS read-write 957 STATUS current 958 DESCRIPTION "If this object is set to true then securityNames 959 passing to and from the application are expected to 960 contain a transport domain specific prefix. If this 961 object is set to true then a domain specific prefix 962 will be added by the TSM to the securityName for 963 incoming messages and removed from the securityName 964 when processing outgoing messages. Transport domains 965 and prefixes are maintained in a registry by IANA. 966 This object SHOULD persist across system reboots. 967 " 968 DEFVAL { false } 969 ::= { snmpTsmConfiguration 1 } 971 -- ------------------------------------------------------------- 972 -- snmpTsmMIB - Conformance Information 973 -- ------------------------------------------------------------- 975 snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 } 977 snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 } 979 -- ------------------------------------------------------------- 980 -- Compliance statements 981 -- ------------------------------------------------------------- 983 snmpTsmCompliance MODULE-COMPLIANCE 984 STATUS current 985 DESCRIPTION "The compliance statement for SNMP engines that support 986 the SNMP-TSM-MIB 987 " 988 MODULE 989 MANDATORY-GROUPS { snmpTsmGroup } 990 ::= { snmpTsmCompliances 1 } 992 -- ------------------------------------------------------------- 993 -- Units of conformance 994 -- ------------------------------------------------------------- 995 snmpTsmGroup OBJECT-GROUP 996 OBJECTS { 997 snmpTsmInvalidCaches, 998 snmpTsmInadequateSecurityLevels, 999 snmpTsmUnknownPrefixes, 1000 snmpTsmInvalidPrefixes, 1001 snmpTsmConfigurationUsePrefix 1002 } 1003 STATUS current 1004 DESCRIPTION "A collection of objects for maintaining 1005 information of an SNMP engine which implements 1006 the SNMP Transport Security Model. 1007 " 1009 ::= { snmpTsmGroups 2 } 1011 END 1013 8. Security Considerations 1015 This document describes a Security Model, compatible with the RFC3411 1016 architecture, that permits SNMP to utilize security services provided 1017 through an SNMP Transport Model. The Transport Security Model relies 1018 on Transport Models for mutual authentication, binding of keys, 1019 confidentiality and integrity. 1021 The Transport Security Model relies on secure Transport Models to 1022 provide an authenticated principal identifier and an assertion of 1023 whether authentication and privacy are used during transport. This 1024 Security Model SHOULD always be used with Transport Models that 1025 provide adequate security, but "adequate security" is a configuration 1026 and/or run-time decision of the operator or management application. 1027 The security threats and how these threats are mitigated should be 1028 covered in detail in the specifications of the Transport Models and 1029 the underlying secure transports. 1031 An authenticated principal identifier (securityName) is used in SNMP 1032 applications, for purposes such as access control, notification 1033 generation, and proxy forwarding. This security model supports 1034 multiple transport models. Operators might judge some transports to 1035 be more secure than others, so this security model can be configured 1036 to prepend a prefix to the securityName to indicate the transport 1037 model used to authenticate the principal. Operators can use the 1038 prefixed securityName when making application decisions about levels 1039 of access. 1041 8.1. MIB module security 1043 There are a number of management objects defined in this MIB module 1044 with a MAX-ACCESS clause of read-write and/or read-create. Such 1045 objects may be considered sensitive or vulnerable in some network 1046 environments. The support for SET operations in a non-secure 1047 environment without proper protection can have a negative effect on 1048 network operations. These are the tables and objects and their 1049 sensitivity/vulnerability: 1051 o The snmpTsmConfigurationUsePrefix object could be modified, 1052 creating a denial of service or authorizing SNMP messages that 1053 would not have previously been authorized by an Access Control 1054 Model (e.g. the VACM). 1056 Some of the readable objects in this MIB module (i.e., objects with a 1057 MAX-ACCESS other than not-accessible) may be considered sensitive or 1058 vulnerable in some network environments. It is thus important to 1059 control even GET and/or NOTIFY access to these objects and possibly 1060 to even encrypt the values of these objects when sending them over 1061 the network via SNMP. These are the tables and objects and their 1062 sensitivity/vulnerability: 1064 o All the counters in this module refer to configuration errors and 1065 do not expose sensitive information. 1067 SNMP versions prior to SNMPv3 did not include adequate security. 1068 Even if the network itself is secure (for example by using IPsec), 1069 even then, there is no control as to who on the secure network is 1070 allowed to access and GET/SET (read/change/create/delete) the objects 1071 in this MIB module. 1073 It is RECOMMENDED that implementers consider the security features as 1074 provided by the SNMPv3 framework (see [RFC3410] section 8), including 1075 full support for the USM and Transport Security Model cryptographic 1076 mechanisms (for authentication and privacy). 1078 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1079 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1080 enable cryptographic security. It is then a customer/operator 1081 responsibility to ensure that the SNMP entity giving access to an 1082 instance of this MIB module is properly configured to give access to 1083 the objects only to those principals (users) that have legitimate 1084 rights to indeed GET or SET (change/create/delete) them. 1086 9. IANA Considerations 1088 IANA is requested to assign: 1090 1. an SMI number under mib-2, for the MIB module in this document, 1092 2. a value, preferably 4, to identify the Transport Security Model, 1093 in the Security Models registry at 1094 http://www.iana.org/assignments/snmp-number-spaces. This should 1095 result in the following table of values: 1097 Value Description References 1098 ----- ----------- ---------- 1099 0 reserved for 'any' [RFC3411] 1100 1 reserved for SNMPv1 [RFC3411] 1101 2 reserved for SNMPv2c [RFC3411] 1102 3 User-Based Security Model (USM) [RFC3411] 1103 YY Transport Security Model (TSM) [RFCXXXX] 1105 -- NOTE to RFC editor: replace XXXX with actual RFC number 1106 -- for this document and remove this note 1107 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 1108 throughout this document and remove this note. 1110 10. Acknowledgements 1112 The editors would like to thank Jeffrey Hutzelman for sharing his SSH 1113 insights, and Dave Shield for an outstanding job wordsmithing the 1114 existing document to improve organization and clarity. 1116 Additionally, helpful document reviews were received from: Juergen 1117 Schoenwaelder. 1119 11. References 1121 11.1. Normative References 1123 [RFC2119] Bradner, S., "Key words for use in RFCs to 1124 Indicate Requirement Levels", BCP 14, RFC 2119, 1125 March 1997. 1127 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1128 Schoenwaelder, Ed., "Structure of Management 1129 Information Version 2 (SMIv2)", STD 58, 1130 RFC 2578, April 1999. 1132 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1133 Schoenwaelder, Ed., "Textual Conventions for 1134 SMIv2", STD 58, RFC 2579, April 1999. 1136 [RFC2580] McCloghrie, K., Perkins, D., and J. 1137 Schoenwaelder, "Conformance Statements for 1138 SMIv2", STD 58, RFC 2580, April 1999. 1140 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1141 Architecture for Describing Simple Network 1142 Management Protocol (SNMP) Management 1143 Frameworks", STD 62, RFC 3411, December 2002. 1145 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 1146 Wijnen, "Message Processing and Dispatching for 1147 the Simple Network Management Protocol (SNMP)", 1148 STD 62, RFC 3412, December 2002. 1150 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 1151 Network Management Protocol (SNMP) 1152 Applications", STD 62, RFC 3413, December 2002. 1154 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 1155 Subsystem for the Simple Network Management 1156 Protocol (SNMP)", draft-ietf-isms-tmsm-14 (work 1157 in progress), October 2008. 1159 11.2. Informative References 1161 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1162 Stewart, "Introduction and Applicability 1163 Statements for Internet-Standard Management 1164 Framework", RFC 3410, December 2002. 1166 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 1167 Security Model (USM) for version 3 of the 1168 Simple Network Management Protocol (SNMPv3)", 1169 STD 62, RFC 3414, December 2002. 1171 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, 1172 "View-based Access Control Model (VACM) for the 1173 Simple Network Management Protocol (SNMP)", 1174 STD 62, RFC 3415, December 2002. 1176 [RFC3418] Presuhn, R., "Management Information Base (MIB) 1177 for the Simple Network Management Protocol 1178 (SNMP)", STD 62, RFC 3418, December 2002. 1180 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 1181 Wijnen, "Coexistence between Version 1, Version 1182 2, and Version 3 of the Internet-standard 1183 Network Management Framework", BCP 74, 1184 RFC 3584, August 2003. 1186 Appendix A. Notification Tables Configuration 1188 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 1189 configure notification originators with the destinations to which 1190 notifications should be sent. 1192 Most of the configuration is security-model-independent and 1193 transport-model-independent. 1195 The values we will use in the examples for the five model-independent 1196 security and transport parameters are: 1198 transportDomain = snmpSSHDomain 1200 transportAddress = 192.0.2.1:162 1202 securityModel = Transport Security Model 1204 securityName = sampleUser 1205 securityLevel = authPriv 1207 The following example will configure the Notification Originator to 1208 send informs to a Notification Receiver at host 192.0.2.1 port 162 1209 using the securityName "sampleUser". The columns marked with a "*" 1210 are the items that are Security Model or Transport Model specific. 1212 The configuration for the "sampleUser" settings in the SNMP-VIEW- 1213 BASED-ACM-MIB objects are not shown here for brevity. First we 1214 configure which type of notification should be sent for this taglist 1215 (toCRTag). In this example, we choose to send an Inform. 1216 snmpNotifyTable row: 1217 snmpNotifyName CRNotif 1218 snmpNotifyTag toCRTag 1219 snmpNotifyType inform 1220 snmpNotifyStorageType nonVolatile 1221 snmpNotifyColumnStatus createAndGo 1223 Then we configure a transport address to which notifications 1224 associated with this taglist should be sent, and we specify which 1225 snmpTargetParamsEntry should be used (toCR) when sending to this 1226 transport address. 1227 snmpTargetAddrTable row: 1228 snmpTargetAddrName toCRAddr 1229 * snmpTargetAddrTDomain snmpSSHDomain 1230 snmpTargetAddrTAddress 192.0.2.1:162 1231 snmpTargetAddrTimeout 1500 1232 snmpTargetAddrRetryCount 3 1233 snmpTargetAddrTagList toCRTag 1234 snmpTargetAddrParams toCR (must match below) 1235 snmpTargetAddrStorageType nonVolatile 1236 snmpTargetAddrColumnStatus createAndGo 1238 Then we configure which principal at the host should receive the 1239 notifications associated with this taglist. Here we choose 1240 "sampleUser", who uses the Transport Security Model. 1241 snmpTargetParamsTable row: 1242 snmpTargetParamsName toCR 1243 snmpTargetParamsMPModel SNMPv3 1244 * snmpTargetParamsSecurityModel TransportSecurityModel 1245 snmpTargetParamsSecurityName "sampleUser" 1246 snmpTargetParamsSecurityLevel authPriv 1247 snmpTargetParamsStorageType nonVolatile 1248 snmpTargetParamsRowStatus createAndGo 1250 A.1. Transport Security Model Processing for Notifications 1252 The Transport Security Model is called using the generateRequestMsg() 1253 ASI, with the following parameters (* are from the above tables): 1255 statusInformation = -- success or errorIndication 1256 generateRequestMsg( 1257 IN messageProcessingModel -- *snmpTargetParamsMPModel 1258 IN globalData -- message header, admin data 1259 IN maxMessageSize -- of the sending SNMP entity 1260 IN transportDomain -- *snmpTargetAddrTDomain 1261 IN transportAddress -- *snmpTargetAddrTAddress 1262 IN securityModel -- *snmpTargetParamsSecurityModel 1263 IN securityEngineID -- immaterial; TSM will ignore. 1264 IN securityName -- snmpTargetParamsSecurityName 1265 IN securityLevel -- *snmpTargetParamsSecurityLevel 1266 IN scopedPDU -- message (plaintext) payload 1267 OUT securityParameters -- filled in by Security Module 1268 OUT wholeMsg -- complete generated message 1269 OUT wholeMsgLength -- length of generated message 1270 OUT tmStateReference -- reference to transport info 1271 ) 1273 The Transport Security Model will determine the Transport Model based 1274 on the snmpTargetAddrTDomain. The selected Transport Model will 1275 select the appropriate transport connection using the 1276 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1277 snmpTargetParamsSecurityLevel. 1279 Appendix B. Processing Differences between USM and Secure Transport 1281 USM and secure transports differ in the processing order and 1282 responsibilities within the RFC3411 architecture. While the steps 1283 are the same, they occur in a different order, and may be done by 1284 different subsystems. The following lists illustrate the difference 1285 in the flow and the responsibility for different processing steps for 1286 incoming messages when using USM and when using a secure transport. 1287 (These lists are simplified for illustrative purposes, and do not 1288 represent all details of processing. Transport Models must provide 1289 the detailed elements of procedure.) 1291 With USM, SNMPv1, and SNMPv2c Security Models, security processing 1292 starts when the Message Processing Model decodes portions of the 1293 ASN.1 message to extract header fields that are used to determine 1294 which Security Model should process the message to perform 1295 authentication, decryption, timeliness checking, integrity checking, 1296 and translation of parameters to model-independent parameters. By 1297 comparison, a secure transport performs those security functions on 1298 the message, before the ASN.1 is decoded. 1300 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 1301 are the same for USM and a secure transport. 1303 B.1. USM and the RFC3411 Architecture 1305 1) decode the ASN.1 header (Message Processing Model) 1307 2) determine the SNMP Security Model and parameters (Message 1308 Processing Model) 1310 3) verify securityLevel. [Security Model] 1312 4) translate parameters to model-independent parameters (Security 1313 Model) 1315 5) authenticate the principal, check message integrity and 1316 timeliness, and decrypt the message. [Security Model] 1318 6) determine the pduType in the decrypted portions (Message 1319 Processing Model), and 1321 7) pass on the decrypted portions with model-independent parameters. 1323 B.2. Transport Subsystem and the RFC3411 Architecture 1325 1) authenticate the principal, check integrity and timeliness of the 1326 message, and decrypt the message. [Transport Model] 1328 2) translate parameters to model-independent parameters (Transport 1329 Model) 1331 3) decode the ASN.1 header (Message Processing Model) 1333 4) determine the SNMP Security Model and parameters (Message 1334 Processing Model) 1336 5) verify securityLevel [Security Model] 1338 6) determine the pduType in the decrypted portions (Message 1339 Processing Model), and 1341 7) pass on the decrypted portions with model-independent security 1342 parameters 1344 If a message is secured using a secure transport layer, then the 1345 Transport Model should provide the translation from the authenticated 1346 identity (e.g., an SSH user name) to a human-friendly identifier in 1347 step 2. The security model will provide a mapping from that 1348 identifier to a model-independent securityName. 1350 Appendix C. Open Issues 1352 Appendix D. Change Log 1354 From -09- to -10- 1356 snmpTsmInvalidPrefix -> snmpTsmInvalidPrefixes 1358 Improvements to the prefix handling text in the EOP 1360 Removed transform selection 1362 Removed translation table 1364 Removed option to disable transports. 1366 Removed references to the LCD. 1368 Removed modifications to the "Cached Information" section to keep 1369 this consistent with other ISMS documents. 1371 Eliminated most "Relationship to Other MIB modules" text. 1373 Significant text cleanup 1375 From -08- to -09- 1377 Added the transport domain specific prefix adding/removing support 1378 as agreed to within the ISMS WG. The implementation is a bit 1379 different than what was originally discussed and is now housed 1380 entirely within this document and requires only a string 1381 allocation in the TM documents. In the end this form greatly 1382 reduced the documentation and procedure complexity in most 1383 documents. 1385 Added the snmpTsmConfigurationUsePrefix scalar. 1387 Removed the snmpTsmLCDTable since it is no longer needed. 1389 Removed the snmpTsmLCDDomainTable since it is not needed with the 1390 prefix addition replaced the functionality. 1392 From -07- to -08- 1394 Added tables to the MIB module to define a Transport Security 1395 Model-specific LCD, and updated the Elements of Procedure. This 1396 was because references to an abstract LCD sort of owned by both 1397 the security model and the transport model were found confusing. 1399 Realized we referred to the MIB module in text as SNMP-TRANSPORT- 1400 SM-MIB, but SNMP-TSM-MIB in the module. Changed all occurrences 1401 of SNMP-TRANSPORT-SM-MIB to SNMP-TSM-MIB, following RFC4181 1402 guidelines for naming. 1404 Updated Security Considerations to warn about writable objects, 1405 and added the new counter to the readable objects list. 1407 Changed snmpTsmLCDName to snmpTsmLCDTmSecurityName 1409 From -05- to -06- 1411 Fixed a bunch of editorial nits 1413 Fixed the note about terminology consistent with SNMPv3. 1415 Updated MIB assignment to by rfc4181 compatible 1417 Replaced tmSameSession with tmSameSecurity to eliminate session- 1418 matching from the security model. 1420 Eliminated all reference to the LCD from the Transport Security 1421 Model; the LCD is now TM-specific. 1423 Added tmTransportSecurityLevel and tmRequestedSecurityLevel to 1424 clarify incoming versus outgoing 1426 From -04- to -05- 1428 Removed check for empty securityParameters for incoming messages 1430 Added a note about terminology, for consistency with SNMPv3 rather 1431 than with RFC2828. 1433 From -03- to -04- 1435 Editorial changes requested by Tom Petch, to clarify behavior with 1436 SNMPv1/v2c 1438 Added early discussion of how TSM fits into the architecture to 1439 clarify behavior when RFC3584 security models are co-resident. 1441 Editorial changes requested by Bert Wijnen, to eliminate version- 1442 specific discussions. 1444 Removed sections on version-specific message formats. 1446 Removed discussion of SNMPv3 in Motivation section. 1448 Added discussion of request/response session matching. 1450 From -02- to -03- 1452 Editorial changes suggested by Juergen Schoenwaelder 1454 Capitalized Transport Models, Security Models, and Message 1455 Processing Models, to be consistent with RFC341x conventions. 1457 Eliminated some text that duplicated RFC3412, especially in 1458 Elements of Procedure. 1460 Changed the encoding of msgSecurityParameters 1462 Marked the (NEW) fields added to existing ASIs 1464 Modified text intro discussing relationships to other MIB modules. 1466 From -01- to -02- 1468 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1469 waiting for assignment 1471 cleaned up elements of procedure [todo]s 1473 use the same errorIndication as USM for unsupportedSecurityLevel 1475 fixed syntax of tsmInadequateSecurity counter 1477 changed the "can and will use" the same security parameters to 1478 "can use", to allow responses that have different security 1479 parameters than the request. 1481 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1483 cleaned up "MIB Modules Required for IMPORTS" 1485 From -00- to -01- 1486 made the Transport Model not know anything about the Security 1487 Model. 1489 modified the elements of procedure sections, given the 1490 implications of this change. 1492 simplified elements of procedure, removing most info specified in 1493 architecture/subsystem definitions. 1495 rethought the coexistence section 1497 noted the implications of the Transport Security Model on 1498 isAccessAllowed() 1500 modified all text related to the LCD. 1502 removed most of the MIB (now the TSM has no configuration 1503 parameters). 1505 added counters needed to support elements of procedure 1507 renamed MIB module, and registered under snmpModules 1509 updated IANA and Security Considerations 1511 updated references. 1513 modified the notification configurations. 1515 From SSHSM-04- to Transport-security-model-00 1517 added tsmUserTable 1519 updated Appendix - Notification Tables Configuration 1521 remove open/closed issue appendices 1523 changed tmSessionReference to tmStateReference 1525 Authors' Addresses 1527 David Harrington 1528 Huawei Technologies (USA) 1529 1700 Alma Dr. Suite 100 1530 Plano, TX 75075 1531 USA 1533 Phone: +1 603 436 8634 1534 EMail: dharrington@huawei.com 1536 Wes Hardaker 1537 Sparta, Inc. 1538 P.O. Box 382 1539 Davis, CA 95617 1540 US 1542 Phone: +1 530 792 1913 1543 EMail: ietf@hardakers.net 1545 Full Copyright Statement 1547 Copyright (C) The IETF Trust (2008). 1549 This document is subject to the rights, licenses and restrictions 1550 contained in BCP 78, and except as set forth therein, the authors 1551 retain all their rights. 1553 This document and the information contained herein are provided on an 1554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1561 Intellectual Property 1563 The IETF takes no position regarding the validity or scope of any 1564 Intellectual Property Rights or other rights that might be claimed to 1565 pertain to the implementation or use of the technology described in 1566 this document or the extent to which any license under such rights 1567 might or might not be available; nor does it represent that it has 1568 made any independent effort to identify any such rights. Information 1569 on the procedures with respect to rights in RFC documents can be 1570 found in BCP 78 and BCP 79. 1572 Copies of IPR disclosures made to the IETF Secretariat and any 1573 assurances of licenses to be made available, or the result of an 1574 attempt made to obtain a general license or permission for the use of 1575 such proprietary rights by implementers or users of this 1576 specification can be obtained from the IETF on-line IPR repository at 1577 http://www.ietf.org/ipr. 1579 The IETF invites any interested party to bring to its attention any 1580 copyrights, patents or patent applications, or other proprietary 1581 rights that may cover technology that may be required to implement 1582 this standard. Please address the information to the IETF at 1583 ietf-ipr@ietf.org.