idnits 2.17.1 draft-ietf-isms-transport-security-model-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1246. 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 1018 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects which are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD not be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self-contained, having no direct impact on other modules, and allowing this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. -- 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 18, 2007) is 6003 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 893, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-10 -- 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 November 18, 2007 5 Expires: May 21, 2008 7 Transport Security Model for SNMP 8 draft-ietf-isms-transport-security-model-07 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo describes a Transport Security Model for the Simple Network 42 Management Protocol. 44 This memo also defines a portion of the Management Information Base 45 (MIB) for use with network management protocols in TCP/IP based 46 internets. In particular it defines objects for monitoring and 47 managing the Transport Security Model for SNMP. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. The Internet-Standard Management Framework . . . . . . . . 3 53 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. How the Transport Security Model Fits in the Architecture . . 5 58 2.1. Security Capabilities of this Model . . . . . . . . . . . 6 59 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 61 2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 8 64 2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 9 65 3. Cached Information and References . . . . . . . . . . . . . . 9 66 3.1. tmStateReference . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. securityStateReference . . . . . . . . . . . . . . . . . . 10 68 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 69 4.1. Security Processing for an Outgoing Message . . . . . . . 10 70 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 12 71 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 12 72 5.1. Security Processing for an Incoming Message . . . . . . . 12 73 5.2. Elements of Procedure for Incoming Messages . . . . . . . 13 74 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 14 75 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 14 76 6.2. The tsmStats Subtree . . . . . . . . . . . . . . . . . . . 14 77 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 14 78 6.3.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 14 79 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 15 80 6.3.3. MIB Modules Required for IMPORTS . . . . . . . . . . . 15 81 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 15 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 19 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Appendix A. Notification Tables Configuration . . . . . . . . . . 21 89 A.1. Transport Security Model Processing for Notifications . . 22 90 Appendix B. Processing Differences between USM and Secure 91 Transport . . . . . . . . . . . . . . . . . . . . . . 23 92 B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 24 93 B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 24 94 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 24 95 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 This memo describes a Transport Security Model for the Simple Network 100 Management Protocol, for use with secure Transport Models in the 101 Transport Subsystem [I-D.ietf-isms-tmsm]. 103 This memo also defines a portion of the Management Information Base 104 (MIB) for use with network management protocols in TCP/IP based 105 internets. In particular it defines objects for monitoring and 106 managing the Transport Security Model for SNMP. 108 It is important to understand the SNMP architecture and the 109 terminology of the architecture to understand where the Transport 110 Security Model described in this memo fits into the architecture and 111 interacts with other subsystems and models within the architecture. 112 It is expected that reader will have also read and understood RFC3411 113 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 114 [RFC3418]. 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 For consistency with SNMP-related specifications, this document 134 favors terminology as defined in STD62 rather than favoring 135 terminology that is consistent with non-SNMP specifications that use 136 different variations of the same terminology. This is consistent 137 with the IESG decision to not require the SNMPv3 terminology be 138 modified to match the usage of other non-SNMP specifications when 139 SNMPv3 was advanced to Full Standard. 141 Authentication in this document typically refers to the English 142 meaning of "serving to prove the authenticity of" the message, not 143 data source authentication or peer identity authentication. 145 The terms "manager" and "agent" are not used in this document, 146 because in the RFC 3411 architecture, all SNMP entities have the 147 capability of acting as either manager or agent or both depending on 148 the SNMP applications included in the engine. Where distinction is 149 required, the application names of Command Generator, Command 150 Responder, Notification Originator, Notification Receiver, and Proxy 151 Forwarder are used. See "SNMP Applications" [RFC3413] for further 152 information. 154 While security protocols frequently refer to a user, the terminology 155 used in RFC3411 [RFC3411] and in this memo is "principal". A 156 principal is the "who" on whose behalf services are provided or 157 processing takes place. A principal can be, among other things, an 158 individual acting in a particular role; a set of individuals, with 159 each acting in a particular role; an application or a set of 160 applications, or a combination of these within an administrative 161 domain. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 1.3. Modularity 169 The reader is expected to have read and understood the description of 170 the SNMP architecture, as defined in [RFC3411], and the architecture 171 extension specified in "Transport Subsystem for the Simple Network 172 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 173 external "lower layer transport" protocols to provide message 174 security, tied into the SNMP architecture through the Transport 175 Subsystem. The Transport Security Model is designed to work with 176 such lower-layer secure Transport Models. 178 In keeping with the RFC 3411 design decisions to use self-contained 179 documents, this memo includes the elements of procedure plus 180 associated MIB objects which are needed for processing the Transport 181 Security Model for SNMP. These MIB objects SHOULD not be referenced 182 in other documents. This allows the Transport Security Model to be 183 designed and documented as independent and self-contained, having no 184 direct impact on other modules, and allowing this module to be 185 upgraded and supplemented as the need arises, and to move along the 186 standards track on different time-lines from other modules. 188 This modularity of specification is not meant to be interpreted as 189 imposing any specific requirements on implementation. 191 1.4. Motivation 193 This memo describes a Security Model to make use of Transport Models 194 that use lower layer secure transports and existing and commonly 195 deployed security infrastructures. This Security Model is designed 196 to meet the security and operational needs of network administrators, 197 maximize usability in operational environments to achieve high 198 deployment success and at the same time minimize implementation and 199 deployment costs to minimize the time until deployment is possible. 201 1.5. Constraints 203 The design of this SNMP Security Model is also influenced by the 204 following constraints: 205 1. In times of network stress, the security protocol and its 206 underlying security mechanisms SHOULD NOT depend solely upon the 207 ready availability of other network services (e.g., Network Time 208 Protocol (NTP) or Authentication, Authorization, and Accounting 209 (AAA) protocols). 210 2. When the network is not under stress, the Security Model and its 211 underlying security mechanisms MAY depend upon the ready 212 availability of other network services. 213 3. It may not be possible for the Security Model to determine when 214 the network is under stress. 215 4. A Security Model should require no changes to the SNMP 216 architecture. 217 5. A Security Model should require no changes to the underlying 218 security protocol. 220 2. How the Transport Security Model Fits in the Architecture 222 The Transport Security Model is designed to fit into the RFC3411 223 architecture as a Security Model in the Security Subsystem, and to 224 utilize the services of a secure Transport Model. 226 A cache, referenced by tmStateReference, is used to pass information 227 between the Transport Security Model and a Transport Model, and vice 228 versa. If the Transport Security Model is used with an insecure 229 Transport Model, then the cache will not exist or be populated with 230 security parameters, which will cause the Transport Security Model to 231 return an error (see section 5.2) If another Security Model (eg 232 Community-based Security Model) is used with a secure Transport 233 Model, then the cache may be populated but the other Security Model 234 may be unaware of the cache and ignore its contents (eg deriving the 235 securityName from the Community name in the message instead of 236 deriving it from the tmSecurityName in the tmStateReference cache). 238 When a secure Transport Model creates a tmStateReference cache for an 239 incoming message, it will include a tmTransport, tmAddress, 240 tmSecurityName and a tmTransportSecurityLevel, and it MAY include 241 transport-specific information. When the Transport Security Model 242 sends a message, it will create a cache containing the specified 243 transportDomain, transportAddress, securityName, and securityLevel 244 parameters. The Transport Security Model will pass the 245 tmStateReference to enable the transport model to extract 246 corresponding transport-specific information from the 247 tmStateReference cache, in an implementation-dependent manner. 249 When the Transport Security Model determines that a cache does not 250 yet exist corresponding to the specified transportDomain, 251 transportAddress, secuirtyName, and securityLevel parameters, it 252 creates one that contains a tmSecurityName and 253 tmRequestedSecurityLevel and passes the tmStateReference cache to the 254 specified Transport Model. 256 The Transport Security Model will determine the security-model- 257 independent securityName and securityLevel, and will verify for 258 incoming messages that tmTransportSecurityLevel is at least as strong 259 as the requested securityLevel. 261 To maintain the RFC3411 modularity, the Transport Model does not know 262 which securityModel will be used for an incoming message; the Message 263 Processing Model will determine the securityModel to be used, in a 264 Message Processing Model dependent manner. 266 2.1. Security Capabilities of this Model 268 2.1.1. Threats 270 The Transport Security Model, when used with suitable secure 271 Transport Models, provides protection against the threats identified 272 by the RFC 3411 architecture [RFC3411]. 274 Which threats are addressed depends on the Transport Model. The 275 Transport Security Model does not address any threats itself, but 276 delegates that responsibility to a secure Transport Model. 278 The Transport Security Model is called a Security Model to be 279 compatible with the RFC3411 architecture. However, this Security 280 Model does not provide security mechanisms such as authentication and 281 encryption itself, so it SHOULD always be used with a Transport Model 282 that provides appropriate security. 284 2.1.2. Security Levels 286 The RFC 3411 architecture recognizes three levels of security: 287 - without authentication and without privacy (noAuthNoPriv) 288 - with authentication but without privacy (authNoPriv) 289 - with authentication and with privacy (authPriv) 291 The model-independent securityLevel parameter is used to request 292 specific levels of security for outgoing messages, and to assert that 293 specific levels of security were applied during the transport and 294 processing of incoming messages. 296 The transport layer algorithms used to provide security SHOULD NOT be 297 exposed to the Transport Security Model, as the Transport Security 298 Model has no mechanisms by which it can test whether an assertion 299 made by a Transport Model is accurate. 301 The Transport Security Model trusts that the underlying secure 302 transport connection has been properly configured to support security 303 characteristics at least as strong as reported in 304 tmTransportSecurityLevel. 306 2.2. No Sessions 308 The Transport Security Model will associate state regarding each 309 message and each known remote engine with a combination of 310 transportDomain, transportAddress, securityName, securityModel, and 311 securityLevel. 313 The Transport Security Model does not recognize sessions of any kind, 314 although they may be supported by a transport model. 316 2.3. Coexistence 318 There are two primary factors which determine whether Security Models 319 can coexist. First, there must be a mechanism to select different 320 Security Models at run-time. Second, the processing of one Security 321 Model should not impact the processing of another Security Model. 323 In the RFC3411 architecture, a Message Processing Model determines 324 which Security Model should be called. As of this writing, IANA has 325 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 326 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 327 SNMPv2c, and the User-based Security Model). 329 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 330 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 331 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 332 message. Since there is no field in the message format that permits 333 specifying a Security Model, RFC3584 message processing does not 334 permit the selection of Security Models other than SNMPv1 or SNMPv2. 335 Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or 336 SNMPv2 Message Processing Models **as defined in RFC3584** cannot use 337 the Transport Security Model. (This does not mean an SNMPv1 or 338 SNMPv2 message cannot use a secure transport model, only that the 339 RFC3584 Message Processing Model will not invoke this security 340 model.) 342 The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact 343 for which there is no existing IETF specification. 345 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 346 the securityModel from the msgSecurityModel field of an incoming 347 SNMPv3Message. When the extracted value of msgSecurityModel is 348 transportSecurityModel(YY), security processing is directed to the 349 Transport Security Model. For an outgoing message to be secured 350 using the Transport Security Model, msgSecurityModel should be set to 351 transportSecurityModel(YY). 353 [-- NOTE to RFC editor: replace YY with actual IANA-assigned number, 354 and remove this note. ] 356 The Transport Security Model uses its own MIB module for processing 357 to maintain independence from other Security Models. This allows the 358 Transport Security Model to coexist with other Security Models, such 359 as the User-based Security Model. 361 Note that the Transport Security Model may work with multiple 362 Transport Models, but the isAccessAllowed() application service 363 interfaces (ASI) only accepts a value for the Security Model, not for 364 Transport Models. As a result, it is not possible to have different 365 access control rules for different Transport Models that use the 366 Transport Security Model. 368 2.4. Security Parameter Passing 370 For outgoing messages, Transport Security Model uses parameters 371 provided by the SNMP application to determine if a corresponding 372 tmStateReference cache exists, or to create a suitable 373 tmStateReference cache. The wholeMsg and the tmStateReference are 374 passed to the appropriate Transport Model through a series of ASIs, 375 as described in "Transport Subsystem for the Simple Network 376 Management Protocol" [I-D.ietf-isms-tmsm]. 378 For incoming messages, the Transport Model accepts messages from the 379 lower layer transport, and records the transport-related information 380 and security-related information, including a tmSecurityName that 381 represents the transport-authenticated identity, and a 382 tmTransportSecurityLevel that represents the security features 383 provided during transport, in a cache referenced by tmStateReference. 384 The wholeMsg and the tmStateReference are passed to the appropriate 385 Security Model through a series of ASIs, as described in "Transport 386 Subsystem for the Simple Network Management Protocol" 387 [I-D.ietf-isms-tmsm]. 389 2.5. Notifications and Proxy 391 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 392 management targets, including transportDomain, transportAddress, 393 securityName, securityModel, and securityLevel parameters, for 394 applications such as notifications and proxy. Transport type and 395 address are configured in the snmpTargetAddrTable, and the 396 securityModel, securityName, and securityLevel parameters are 397 configured in the snmpTargetParamsTable. 399 For the Transport Security Model, these will be translated as needed 400 into tmSecurityName and tmRequestedSecurityLevel. 402 The default approach is for an administrator to statically configure 403 this information to identify the targets authorized to receive 404 notifications or perform proxy. 406 3. Cached Information and References 408 The RFC3411 architecture uses caches to store dynamic model-specific 409 information, and uses references in the ASIs to indicate in a model- 410 independent manner which cached information must flow between 411 subsystems. 413 There are two levels of state that may need to be maintained: the 414 security state in a request-response pair, and potentially long-term 415 state relating to transport and security. This document describes 416 caches, and differentiates the tmStateReference from the 417 securityStateReference, but how this is represented internally is an 418 implementation decision. 420 As a general rule, if state information is available when a message 421 being processed gets discarded, the state related to that message 422 should also be discarded, and if state information is available when 423 a relationship between engines is severed, such as the closing of a 424 transport connection, the state information for that relationship 425 might also be discarded. 427 3.1. tmStateReference 429 For each transport model, information about the transport security 430 may be stored in a cache to pass model- and mechanism-specific 431 parameters. 433 For security reasons, the Transport Security Model REQUIRES that the 434 security parameters used for a response are the same as those used 435 for the corresponding request, and passes a tmSameSecurity parameter 436 in the tmStateReference cache for outgoing messages to indicate that 437 the same security MUST be used for the outgoing response as was used 438 for the corresponding incoming request. It is transport-model- 439 dependent and implementation-dependent how this is ensured at the 440 transport layer. 442 Since the contents of a cache are meaningful only within an 443 implementation, and not on-the-wire, the format of the cache is 444 implementation-specific. 446 3.2. securityStateReference 448 The securityStateReference parameter is defined in RFC3411. Its 449 primary purpose is to provide a mapping between a request and the 450 corresponding response. A sample model-specific cache can be found 451 in RFC3414 [RFC3414]. 453 Transport models do not have access to the securityStateReference. 454 For the Transport Security Model, it is important to ensure that the 455 security parameters used for a request match those used for the 456 corresponding response. The Transport Security Model will 457 conceptually add the tmStateReference to the securityStateReference 458 cache, so the transport model can map transport-specific security 459 parameters for a request to its corresponding response. How the 460 tmStateReference is added to the securityStateReference is 461 implementation-specific. 463 4. Processing an Outgoing Message 465 An error indication may return an OID and value for an incremented 466 counter and a value for securityLevel, and values for contextEngineID 467 and contextName for the counter, and the securityStateReference if 468 the information is available at the point where the error is 469 detected. 471 4.1. Security Processing for an Outgoing Message 473 This section describes the procedure followed by the Transport 474 Security Model. 476 The parameters needed for generating a message are supplied to the 477 Security Model by the Message Processing Model via the 478 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 479 Subsystem architectural extension has added the transportDomain, 480 transportAddress, and tmStateReference parameters to the original 481 RFC3411 ASIs. 483 statusInformation = -- success or errorIndication 484 generateRequestMsg( 485 IN messageProcessingModel -- typically, SNMP version 486 IN globalData -- message header, admin data 487 IN maxMessageSize -- of the sending SNMP entity 488 IN transportDomain -- (NEW) specified by application 489 IN transportAddress -- (NEW) specified by application 490 IN securityModel -- for the outgoing message 491 IN securityEngineID -- authoritative SNMP entity 492 IN securityName -- on behalf of this principal 493 IN securityLevel -- Level of Security requested 494 IN scopedPDU -- message (plaintext) payload 495 OUT securityParameters -- filled in by Security Module 496 OUT wholeMsg -- complete generated message 497 OUT wholeMsgLength -- length of generated message 498 OUT tmStateReference -- (NEW) transport info 499 ) 501 statusInformation = -- success or errorIndication 502 generateResponseMsg( 503 IN messageProcessingModel -- typically, SNMP version 504 IN globalData -- message header, admin data 505 IN maxMessageSize -- of the sending SNMP entity 506 IN transportDomain -- (NEW) specified by application 507 IN transportAddress -- (NEW) specified by application 508 IN securityModel -- for the outgoing message 509 IN securityEngineID -- authoritative SNMP entity 510 IN securityName -- on behalf of this principal 511 IN securityLevel -- Level of Security requested 512 IN scopedPDU -- message (plaintext) payload 513 IN securityStateReference -- reference to security state 514 -- information from original 515 -- request 516 OUT securityParameters -- filled in by Security Module 517 OUT wholeMsg -- complete generated message 518 OUT wholeMsgLength -- length of generated message 519 OUT tmStateReference -- (NEW) transport info 520 ) 522 4.2. Elements of Procedure for Outgoing Messages 524 1) If there is a securityStateReference, then this is a response 525 message. Extract transportDomain, transportAddress, securityName, 526 securityLevel, securityModel, and tmStateReference from the 527 securityStateReference cache. Set the tmRequestedSecurityLevel to 528 the value of the extracted securityLevel. The cachedSecurityData for 529 this message can now be discarded. Set the tmSameSecurity parameter 530 in the tmStateReference cache to true. 532 2) If there is no securityStateReference, create a tmStateReference 533 cache with tmSecurityName set to the value of securityName, 534 tmRequestedSecurityLevel set to the value of securityLevel, and 535 tmSameSecurity set to false. 537 3) Fill in the securityParameters with a zero-length OCTET STRING 538 ('0400'). 540 4) Combine the message parts into a wholeMsg and calculate 541 wholeMsgLength. 543 5) The wholeMsg, wholeMsgLength, securityParameters and 544 tmStateReference are returned to the calling Message Processing Model 545 with the statusInformation set to success. 547 5. Processing an Incoming SNMP Message 549 An error indication may return an OID and value for an incremented 550 counter and a value for securityLevel, and values for contextEngineID 551 and contextName for the counter, and the securityStateReference if 552 the information is available at the point where the error is 553 detected. 555 5.1. Security Processing for an Incoming Message 557 This section describes the procedure followed by the Transport 558 Security Model whenever it receives an incoming message from a 559 Message Processing Model. The ASI from a Message Processing Model to 560 the Security Subsystem for a received message is: 562 statusInformation = -- errorIndication or success 563 -- error counter OID/value if error 564 processIncomingMsg( 565 IN messageProcessingModel -- typically, SNMP version 566 IN maxMessageSize -- from the received message 567 IN securityParameters -- from the received message 568 IN securityModel -- from the received message 569 IN securityLevel -- from the received message 570 IN wholeMsg -- as received on the wire 571 IN wholeMsgLength -- length as received on the wire 572 IN tmStateReference -- (NEW) from the Transport Model 573 OUT securityEngineID -- authoritative SNMP entity 574 OUT securityName -- identification of the principal 575 OUT scopedPDU, -- message (plaintext) payload 576 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 577 OUT securityStateReference -- reference to security state 578 ) -- information, needed for response 580 5.2. Elements of Procedure for Incoming Messages 582 1) Set the securityEngineID to the local snmpEngineID. 584 2) If tmStateReference does not refer to a cache containing values 585 for tmSecurityName and tmTransportSecurityLevel, then the 586 snmpTsmInvalidCaches counter is incremented, an error indication is 587 returned to the calling module, and Security Model processing stops 588 for this message. 590 3) Set securityName to the value of tmSecurityName from the cache 591 referenced by tmStateReference. 593 4) Compare the value of tmTransportSecurityLevel in the 594 tmStateReference cache to the value of the securityLevel parameter 595 passed in the processIncomingMsg ASI. If securityLevel specifies 596 privacy (Priv), and tmTransportSecurityLevel specifies no privacy 597 (noPriv), or securityLevel specifies authentication (auth) and 598 tmTransportSecurityLevel specifies no authentication (noAuth) was 599 provided by the Transport Model, then the 600 snmpTsmInadequateSecurityLevels counter is incremented, and an error 601 indication (unsupportedSecurityLevel) together with the OID and value 602 of the incremented counter is returned to the calling module. 603 Transport Security Model processing stops for this message. 605 5)The security data is cached as cachedSecurityData, so that a 606 possible response to this message will use the same security 607 parameters. Then securityStateReference is set for subsequent 608 reference to this cached data. For Transport Security Model, the 609 securityStateReference includes a reference to the tmStateReference 610 cache. 612 6) The scopedPDU component is extracted from the wholeMsg. 614 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 615 size allowed for a scopedPDU for a possible Response message. 617 8) The statusInformation is set to success and a return is made to 618 the calling module passing back the OUT parameters as specified in 619 the processIncomingMsg ASI. 621 6. MIB Module Overview 623 This MIB module provides management of the Transport Security Model. 624 It defines some needed textual conventions, and some statistics. 626 6.1. Structure of the MIB Module 628 Objects in this MIB module are arranged into subtrees. Each subtree 629 is organized as a set of related objects. The overall structure and 630 assignment of objects to their subtrees, and the intended purpose of 631 each subtree, is shown below. 633 6.2. The tsmStats Subtree 635 This subtree contains counters specific to the Transport Security 636 Model, that provide information for identifying fault conditions. 638 6.3. Relationship to Other MIB Modules 640 Some management objects defined in other MIB modules are applicable 641 to an entity implementing the Transport Security Model In particular, 642 it is assumed that an entity implementing the Transport Security 643 Model will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK- 644 MIB [RFC3411]. 646 6.3.1. Relationship to the SNMPv2-MIB 648 The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being 649 mandatory for all systems, and the objects apply to the entity as a 650 whole. The 'system' group provides identification of the management 651 entity and certain other system-wide data. The snmpInASNParseErrs 652 counter is incremented during the elements of procedure. The SNMP- 653 TRANSPORT-SM-MIB does not duplicate those objects. 655 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB 657 The SNMP-FRAMEWORK-MIB provides definitions for the concepts of 658 SnmpEngineID, enumeration of Message Processing Models, Security 659 Models and Security Levels, and object definitions for snmpEngineID 660 These are important for implementing the Transport Security Model, 661 but are not needed to implement the SNMP-TRANSPORT-SM-MIB. 663 6.3.3. MIB Modules Required for IMPORTS 665 The following MIB module imports items from [RFC2578] and [RFC2580]. 667 7. MIB module definition 669 SNMP-TSM-MIB DEFINITIONS ::= BEGIN 671 IMPORTS 672 MODULE-IDENTITY, OBJECT-TYPE, 673 mib-2, Counter32 674 FROM SNMPv2-SMI 675 MODULE-COMPLIANCE, OBJECT-GROUP 676 FROM SNMPv2-CONF 677 ; 679 snmpTsmMIB MODULE-IDENTITY 680 LAST-UPDATED "200710140000Z" 681 ORGANIZATION "ISMS Working Group" 682 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 683 Subscribe: isms-request@lists.ietf.org 685 Chairs: 686 Juergen Quittek 687 NEC Europe Ltd. 688 Network Laboratories 689 Kurfuersten-Anlage 36 690 69115 Heidelberg 691 Germany 692 +49 6221 90511-15 693 quittek@netlab.nec.de 695 Juergen Schoenwaelder 696 Jacobs University Bremen 697 Campus Ring 1 698 28725 Bremen 699 Germany 700 +49 421 200-3587 701 j.schoenwaelder@iu-bremen.de 703 Editor: 704 David Harrington 705 Huawei Technologies USA 706 1700 Alma Dr. 707 Plano TX 75075 708 USA 709 +1 603-436-8634 710 ietfdbh@comcast.net 711 " 712 DESCRIPTION "The Transport Security Model MIB 714 In keeping with the RFC 3411 design decisions 715 to use self-contained documents, the RFC which 716 contains the definition of this MIB module also 717 includes the elements of procedure which are 718 needed for processing the Transport Security 719 Model for SNMP. These MIB objects 720 SHOULD NOT be modified via other documents. 721 This allows the Transport Security Model 722 for SNMP to be designed and documented as 723 independent and self- contained, having no 724 direct impact on other modules, and this 725 allows this module to be upgraded and 726 supplemented as the need arises, and to 727 move along the standards track on different 728 time-lines from other modules. 730 Copyright (C) The IETF Trust (2007). This 731 version of this MIB module is part of RFC XXXX; 732 see the RFC itself for full legal notices. 733 -- NOTE to RFC editor: replace XXXX with actual RFC number 734 -- for this document and remove this note 735 " 737 REVISION "200710140000Z" 738 DESCRIPTION "The initial version, published in RFC XXXX. 739 -- NOTE to RFC editor: replace XXXX with actual RFC number 740 -- for this document and remove this note 741 " 743 ::= { mib-2 xxxx } 744 -- RFC Ed.: replace xxxx with IANA-assigned number and 745 -- remove this note 747 -- ---------------------------------------------------------- -- 748 -- subtrees in the SNMP-TRANSPORT-SM-MIB 749 -- ---------------------------------------------------------- -- 750 snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 } 751 snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 } 752 snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 } 754 -- ------------------------------------------------------------- 755 -- Objects 756 -- ------------------------------------------------------------- 758 -- Statistics for the Transport Security Model 760 snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 } 762 snmpTsmInvalidCaches OBJECT-TYPE 763 SYNTAX Counter32 764 MAX-ACCESS read-only 765 STATUS current 766 DESCRIPTION "The number of messages dropped because the 767 tmStateReference referred to an invalid cache. 768 " 769 ::= { snmpTsmStats 1 } 771 snmpTsmInadequateSecurityLevels OBJECT-TYPE 772 SYNTAX Counter32 773 MAX-ACCESS read-only 774 STATUS current 775 DESCRIPTION "The number of incoming messages dropped because 776 the actual securityLevel provided was less than 777 the requested securityLevel. 778 " 779 ::= { snmpTsmStats 2 } 781 -- ------------------------------------------------------------- 782 -- snmpTsmMIB - Conformance Information 783 -- ------------------------------------------------------------- 785 snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 } 787 snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 } 789 -- ------------------------------------------------------------- 790 -- Compliance statements 791 -- ------------------------------------------------------------- 793 snmpTsmCompliance MODULE-COMPLIANCE 794 STATUS current 795 DESCRIPTION 796 "The compliance statement for SNMP engines that support 797 the SNMP-TRANSPORT-SM-MIB" 798 MODULE 799 MANDATORY-GROUPS { snmpTsmGroup } 800 ::= { snmpTsmCompliances 1 } 802 -- ------------------------------------------------------------- 803 -- Units of conformance 804 -- ------------------------------------------------------------- 805 snmpTsmGroup OBJECT-GROUP 806 OBJECTS { 807 snmpTsmInvalidCaches, 808 snmpTsmInadequateSecurityLevels 809 } 810 STATUS current 811 DESCRIPTION "A collection of objects for maintaining 812 information of an SNMP engine which implements 813 the SNMP Transport Security Model. 814 " 816 ::= { snmpTsmGroups 2 } 818 END 820 8. Security Considerations 822 This document describes a Security Model that permits SNMP to utilize 823 security services provided through an SNMP Transport Model. The 824 Transport Security Model relies on Transport Models for mutual 825 authentication, binding of keys, confidentiality and integrity. The 826 security threats and how those threats are mitigated should be 827 covered in detail in the specification of the Transport Model and the 828 underlying secure transport. 830 Transport Security Model relies on a Transport Model to provide an 831 authenticated principal for mapping to securityName, and an assertion 832 of tmTransportSecurityLevel. 834 The Transport Security Model is called a Security Model to be 835 compatible with the RFC3411 architecture. However, this Security 836 Model provides no security itself. It SHOULD always be used with a 837 Transport Model that provides security, but this is a run-time 838 decision of the operator or management application, or a 839 configuration decision of an operator. 841 8.1. MIB module security 843 There are no management objects defined in this MIB module that have 844 a MAX-ACCESS clause of read-write and/or read-create. So, if this 845 MIB module is implemented correctly, then there is no risk that an 846 intruder can alter or create any management objects of this MIB 847 module via direct SNMP SET operations. 849 Some of the readable objects in this MIB module (i.e., objects with a 850 MAX-ACCESS other than not-accessible) may be considered sensitive or 851 vulnerable in some network environments. It is thus important to 852 control even GET and/or NOTIFY access to these objects and possibly 853 to even encrypt the values of these objects when sending them over 854 the network via SNMP. These are the tables and objects and their 855 sensitivity/vulnerability: 856 o snmpTsmInvalidCaches and snmpTsmInadequateSecurityLevels may make 857 it easier for an attacker to detect vulnerabilities. 859 SNMP versions prior to SNMPv3 did not include adequate security. 860 Even if the network itself is secure (for example by using IPsec), 861 even then, there is no control as to who on the secure network is 862 allowed to access and GET/SET (read/change/create/delete) the objects 863 in this MIB module. 865 It is RECOMMENDED that implementers consider the security features as 866 provided by the SNMPv3 framework (see [RFC3410] section 8), including 867 full support for the USM and Transport Security Model cryptographic 868 mechanisms (for authentication and privacy). 870 Further, deployment of SNMP versions prior to SNMPv3 is NOT 871 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 872 enable cryptographic security. It is then a customer/operator 873 responsibility to ensure that the SNMP entity giving access to an 874 instance of this MIB module is properly configured to give access to 875 the objects only to those principals (users) that have legitimate 876 rights to indeed GET or SET (change/create/delete) them. 878 9. IANA Considerations 880 IANA is requested to assign: 881 1. an SMI number under mib-2, for the MIB module in this document, 882 2. a value, preferably 4, to identify the Transport Security Model, 883 in the Security Models registry at 884 http://www.iana.org/assignments/snmp-number-spaces. This should 885 result in the following table of values: 887 Value Description References 888 ----- ----------- ---------- 889 0 reserved for 'any' [RFC3411] 890 1 reserved for SNMPv1 [RFC3411] 891 2 reserved for SNMPv2c [RFC3411] 892 3 User-Based Security Model (USM) [RFC3411] 893 YY Transport Security Model (TSM) [RFCXXXX] 895 -- NOTE to RFC editor: replace XXXX with actual RFC number 896 -- for this document and remove this note 897 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 898 throughout this document and remove this note. 900 10. References 902 10.1. Normative References 904 [RFC2119] Bradner, S., "Key words for use in RFCs to 905 Indicate Requirement Levels", BCP 14, RFC 2119, 906 March 1997. 908 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 909 Schoenwaelder, Ed., "Structure of Management 910 Information Version 2 (SMIv2)", STD 58, 911 RFC 2578, April 1999. 913 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 914 Schoenwaelder, Ed., "Textual Conventions for 915 SMIv2", STD 58, RFC 2579, April 1999. 917 [RFC2580] McCloghrie, K., Perkins, D., and J. 918 Schoenwaelder, "Conformance Statements for 919 SMIv2", STD 58, RFC 2580, April 1999. 921 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 922 Architecture for Describing Simple Network 923 Management Protocol (SNMP) Management 924 Frameworks", STD 62, RFC 3411, December 2002. 926 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 927 Wijnen, "Message Processing and Dispatching for 928 the Simple Network Management Protocol (SNMP)", 929 STD 62, RFC 3412, December 2002. 931 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 932 Network Management Protocol (SNMP) 933 Applications", STD 62, RFC 3413, December 2002. 935 [RFC3418] Presuhn, R., "Management Information Base (MIB) 936 for the Simple Network Management Protocol 937 (SNMP)", STD 62, RFC 3418, December 2002. 939 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 940 Subsystem for the Simple Network Management 941 Protocol (SNMP)", draft-ietf-isms-tmsm-10 (work 942 in progress), September 2007. 944 10.2. Informative References 946 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 947 Stewart, "Introduction and Applicability 948 Statements for Internet-Standard Management 949 Framework", RFC 3410, December 2002. 951 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 952 Security Model (USM) for version 3 of the 953 Simple Network Management Protocol (SNMPv3)", 954 STD 62, RFC 3414, December 2002. 956 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 957 Wijnen, "Coexistence between Version 1, Version 958 2, and Version 3 of the Internet-standard 959 Network Management Framework", BCP 74, 960 RFC 3584, August 2003. 962 Appendix A. Notification Tables Configuration 964 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 965 configure notification originators with the destinations to which 966 notifications should be sent. 968 Most of the configuration is security-model-independent and 969 transport-model-independent. 971 The values we will use in the examples for the five model-independent 972 security and transport parameters are: 973 transportDomain = snmpSSHDomain 974 transportAddress = 192.0.2.1:162 975 securityModel = Transport Security Model 976 securityName = sampleUser 977 securityLevel = authPriv 979 The following example will configure the Notification Originator to 980 send informs to a Notification Receiver at host 192.0.2.1 port 162 981 using the securityName "sampleUser". The columns marked with a "*" 982 are the items that are Security Model or Transport Model specific. 984 The configuration for the "sampleUser" settings in the SNMP-VIEW- 985 BASED-ACM-MIB objects are not shown here for brevity. First we 986 configure which type of notification should be sent for this taglist 987 (toCRTag). In this example, we choose to send an Inform. 988 snmpNotifyTable row: 989 snmpNotifyName CRNotif 990 snmpNotifyTag toCRTag 991 snmpNotifyType inform 992 snmpNotifyStorageType nonVolatile 993 snmpNotifyColumnStatus createAndGo 995 Then we configure a transport address to which notifications 996 associated with this taglist should be sent, and we specify which 997 snmpTargetParamsEntry should be used (toCR) when sending to this 998 transport address. 999 snmpTargetAddrTable row: 1000 snmpTargetAddrName toCRAddr 1001 * snmpTargetAddrTDomain snmpSSHDomain 1002 snmpTargetAddrTAddress 192.0.2.1:162 1003 snmpTargetAddrTimeout 1500 1004 snmpTargetAddrRetryCount 3 1005 snmpTargetAddrTagList toCRTag 1006 snmpTargetAddrParams toCR (must match below) 1007 snmpTargetAddrStorageType nonVolatile 1008 snmpTargetAddrColumnStatus createAndGo 1010 Then we configure which principal at the host should receive the 1011 notifications associated with this taglist. Here we choose 1012 "sampleUser", who uses the Transport Security Model. 1013 snmpTargetParamsTable row: 1014 snmpTargetParamsName toCR 1015 snmpTargetParamsMPModel SNMPv3 1016 * snmpTargetParamsSecurityModel TransportSecurityModel 1017 snmpTargetParamsSecurityName "sampleUser" 1018 snmpTargetParamsSecurityLevel authPriv 1019 snmpTargetParamsStorageType nonVolatile 1020 snmpTargetParamsRowStatus createAndGo 1022 A.1. Transport Security Model Processing for Notifications 1024 The Transport Security Model is called using the generateRequestMsg() 1025 ASI, with the following parameters (* are from the above tables): 1027 statusInformation = -- success or errorIndication 1028 generateRequestMsg( 1029 IN messageProcessingModel -- *snmpTargetParamsMPModel 1030 IN globalData -- message header, admin data 1031 IN maxMessageSize -- of the sending SNMP entity 1032 IN transportDomain -- *snmpTargetAddrTDomain 1033 IN transportAddress -- *snmpTargetAddrTAddress 1034 IN securityModel -- *snmpTargetParamsSecurityModel 1035 IN securityEngineID -- immaterial; TSM will ignore. 1036 IN securityName -- snmpTargetParamsSecurityName 1037 IN securityLevel -- *snmpTargetParamsSecurityLevel 1038 IN scopedPDU -- message (plaintext) payload 1039 OUT securityParameters -- filled in by Security Module 1040 OUT wholeMsg -- complete generated message 1041 OUT wholeMsgLength -- length of generated message 1042 OUT tmStateReference -- reference to transport info 1043 ) 1045 The Transport Security Model will determine the Transport Model based 1046 on the snmpTargetAddrTDomain. The selected Transport Model will 1047 select the appropriate transport connection using the 1048 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1049 snmpTargetParamsSecurityLevel. 1051 Appendix B. Processing Differences between USM and Secure Transport 1053 USM and secure transports differ in the processing order and 1054 responsibilities within the RFC3411 architecture. While the steps 1055 are the same, they occur in a different order, and may be done by 1056 different subsystems. The following lists illustrate the difference 1057 in the flow and the responsibility for different processing steps for 1058 incoming messages when using USM and when using a secure transport. 1059 (Note that these lists are simplified for illustrative purposes, and 1060 do not represent all details of processing. Transport Models must 1061 provide the detailed elements of procedure.) 1063 With USM and other Security Models, security processing starts when 1064 the Message Processing Model decodes portions of the ASN.1 message to 1065 extract an opaque block of security parameters and header parameters 1066 that identify which Security Model should process the message to 1067 perform authentication, decryption, timeliness checking, integrity 1068 checking, and translation of parameters to model-independent 1069 parameters. A secure transport performs those security functions on 1070 the message, before the ASN.1 is decoded. 1072 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 1073 are the same for USM and a secure transport. 1075 B.1. USM and the RFC3411 Architecture 1077 1) decode the ASN.1 header (Message Processing Model) 1078 2) determine the SNMP Security Model and parameters (Message 1079 Processing Model) 1080 3) verify securityLevel. [Security Model] 1081 4) translate parameters to model-independent parameters (Security 1082 Model) 1083 5) authenticate the principal, check message integrity and 1084 timeliness, and decrypt the message. [Security Model] 1085 6) determine the pduType in the decrypted portions (Message 1086 Processing Model), and 1087 7) pass on the decrypted portions with model-independent parameters. 1089 B.2. Transport Subsystem and the RFC3411 Architecture 1091 1) authenticate the principal, check integrity and timeliness of the 1092 message, and decrypt the message. [Transport Model] 1093 2) translate parameters to model-independent parameters (Transport 1094 Model) 1095 3) decode the ASN.1 header (Message Processing Model) 1096 4) determine the SNMP Security Model and parameters (Message 1097 Processing Model) 1098 5) verify securityLevel [Security Model] 1099 6) determine the pduType in the decrypted portions (Message 1100 Processing Model), and 1101 7) pass on the decrypted portions with model-independent security 1102 parameters 1104 If a message is secured using a secure transport layer, then the 1105 Transport Model should provide the translation from the authenticated 1106 identity (e.g., an SSH user name) to a model-independent securityName 1107 in step 2. 1109 Appendix C. Open Issues 1111 none. 1113 Appendix D. Change Log 1115 From -05- to -06- 1117 Fixed a bunch of editorial nits 1118 Fixed the note about terminology consistent with SNMPv3. 1119 Updated MIB assignment to by rfc4181 compatible 1120 Replaced tmSameSession with tmSameSecurity to eliminate session- 1121 matching from the security model. 1123 Eliminated all reference to the LCD from the Transport Security 1124 Model; the LCD is now TM-specific. 1125 Added tmTransportSecurityLevel and tmRequestedSecurityLevel to 1126 clarify incoming versus outgoing 1128 From -04- to -05- 1130 Removed check for empty securityParameters for incoming messages 1131 Added a note about terminology, for consistency with SNMPv3 rather 1132 than with RFC2828. 1134 From -03- to -04- 1136 Editorial changes requested by Tom Petch, to clarify behavior with 1137 SNMPv1/v2c 1138 Added early discussion of how TSM fits into the architecture to 1139 clarify behavior when RFC3584 security models are co-resident. 1140 Editorial changes requested by Bert Wijnen, to eliminate version- 1141 specific discussions. 1142 Removed sections on version-specific message formats. 1143 Removed discussion of SNMPv3 in Motivation section. 1144 Added discussion of request/response session matching. 1146 From -02- to -03- 1148 Editorial changes suggested by Juergen Schoenwaelder 1149 Capitalized Transport Models, Security Models, and Message 1150 Processing Models, to be consistent with RFC341x conventions. 1151 Eliminated some text that duplicated RFC3412, especially in 1152 Elements of Procedure. 1153 Changed the encoding of msgSecurityParameters 1154 Marked the (NEW) fields added to existing ASIs 1155 Modified text intro discussing relationships to other MIB modules. 1157 From -01- to -02- 1159 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1160 waiting for assignment 1161 cleaned up elements of procedure [todo]s 1162 use the same errorIndication as USM for unsupportedSecurityLevel 1163 fixed syntax of tsmInadequateSecurity counter 1164 changed the "can and will use" the same security parameters to 1165 "can use", to allow responses that have different security 1166 parameters than the request. 1167 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1168 cleaned up "MIB Modules Required for IMPORTS" 1170 From -00- to -01- 1172 made the Transport Model not know anything about the Security 1173 Model. 1174 modified the elements of procedure sections, given the 1175 implications of this change. 1176 simplified elements of procedure, removing most info specified in 1177 architecture/subsystem definitions. 1178 rethought the coexistence section 1179 noted the implications of the Transport Security Model on 1180 isAccessAllowed() 1181 modified all text related to the LCD. 1182 removed most of the MIB (now the TSM has no configuration 1183 parameters). 1184 added counters needed to support elements of procedure 1185 renamed MIB module, and registered under snmpModules 1186 updated IANA and Security Considerations 1187 updated references. 1188 modified the notification configurations. 1190 From SSHSM-04- to Transport-security-model-00 1192 added tsmUserTable 1193 updated Appendix - Notification Tables Configuration 1194 remove open/closed issue appendices 1195 changed tmSessionReference to tmStateReference 1197 Author's Address 1199 David Harrington 1200 Huawei Technologies (USA) 1201 1700 Alma Dr. Suite 100 1202 Plano, TX 75075 1203 USA 1205 Phone: +1 603 436 8634 1206 EMail: dharrington@huawei.com 1208 Full Copyright Statement 1210 Copyright (C) The IETF Trust (2007). 1212 This document is subject to the rights, licenses and restrictions 1213 contained in BCP 78, and except as set forth therein, the authors 1214 retain all their rights. 1216 This document and the information contained herein are provided on an 1217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1219 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1220 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1221 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1224 Intellectual Property 1226 The IETF takes no position regarding the validity or scope of any 1227 Intellectual Property Rights or other rights that might be claimed to 1228 pertain to the implementation or use of the technology described in 1229 this document or the extent to which any license under such rights 1230 might or might not be available; nor does it represent that it has 1231 made any independent effort to identify any such rights. Information 1232 on the procedures with respect to rights in RFC documents can be 1233 found in BCP 78 and BCP 79. 1235 Copies of IPR disclosures made to the IETF Secretariat and any 1236 assurances of licenses to be made available, or the result of an 1237 attempt made to obtain a general license or permission for the use of 1238 such proprietary rights by implementers or users of this 1239 specification can be obtained from the IETF on-line IPR repository at 1240 http://www.ietf.org/ipr. 1242 The IETF invites any interested party to bring to its attention any 1243 copyrights, patents or patent applications, or other proprietary 1244 rights that may cover technology that may be required to implement 1245 this standard. Please address the information to the IETF at 1246 ietf-ipr@ietf.org. 1248 Acknowledgement 1250 Funding for the RFC Editor function is provided by the IETF 1251 Administrative Support Activity (IASA).