idnits 2.17.1 draft-ietf-isms-transport-security-model-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == Line 1153 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2009) is 5477 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 995, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-16 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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: October 29, 2009 Sparta, Inc. 6 April 27, 2009 8 Transport Security Model for SNMP 9 draft-ietf-isms-transport-security-model-13 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on October 29, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This memo describes a Transport Security Model for the Simple Network 58 Management Protocol. 60 This memo also defines a portion of the Management Information Base 61 (MIB) for monitoring and managing the Transport Security Model for 62 SNMP. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. The Internet-Standard Management Framework . . . . . . . . 4 68 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 72 2. How the Transport Security Model Fits in the Architecture . . 6 73 2.1. Security Capabilities of this Model . . . . . . . . . . . 7 74 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 76 2.2. Transport Sessions . . . . . . . . . . . . . . . . . . . . 8 77 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.3.1. Coexistence with Message Processing Models . . . . . . 8 79 2.3.2. Coexistence with Other Security Models . . . . . . . . 8 80 2.3.3. Coexistence with Transport Models . . . . . . . . . . 9 81 3. Cached Information and References . . . . . . . . . . . . . . 9 82 3.1. Transport Security Model Cached Information . . . . . . . 9 83 3.1.1. securityStateReference . . . . . . . . . . . . . . . . 9 84 3.1.2. tmStateReference . . . . . . . . . . . . . . . . . . . 9 85 3.1.3. Prefixes and securityNames . . . . . . . . . . . . . . 10 86 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 87 4.1. Security Processing for an Outgoing Message . . . . . . . 10 88 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 11 89 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 12 90 5.1. Security Processing for an Incoming Message . . . . . . . 13 91 5.2. Elements of Procedure for Incoming Messages . . . . . . . 13 92 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 14 93 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 14 94 6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 15 95 6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 15 96 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 15 97 6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 15 98 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 15 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 21 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 106 Appendix A. Notification Tables Configuration . . . . . . . . . . 24 107 A.1. Transport Security Model Processing for Notifications . . 26 108 Appendix B. Processing Differences between USM and Secure 109 Transport . . . . . . . . . . . . . . . . . . . . . . 26 110 B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 27 111 B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 27 113 1. Introduction 115 This memo describes a Transport Security Model for the Simple Network 116 Management Protocol, for use with secure Transport Models in the 117 Transport Subsystem [I-D.ietf-isms-tmsm]. 119 This memo also defines a portion of the Management Information Base 120 (MIB) for monitoring and managing the Transport Security Model for 121 SNMP. 123 It is important to understand the SNMP architecture and the 124 terminology of the architecture to understand where the Transport 125 Security Model described in this memo fits into the architecture and 126 interacts with other subsystems and models within the architecture. 127 It is expected that reader will have also read and understood RFC3411 128 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 129 [RFC3418]. 131 1.1. The Internet-Standard Management Framework 133 For a detailed overview of the documents that describe the current 134 Internet-Standard Management Framework, please refer to section 7 of 135 RFC 3410 [RFC3410]. 137 Managed objects are accessed via a virtual information store, termed 138 the Management Information Base or MIB. MIB objects are generally 139 accessed through the Simple Network Management Protocol (SNMP). 140 Objects in the MIB are defined using the mechanisms defined in the 141 Structure of Management Information (SMI). This memo specifies a MIB 142 module that is compliant to the SMIv2, which is described in STD 58, 143 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 144 [RFC2580]. 146 1.2. Conventions 148 For consistency with SNMP-related specifications, this document 149 favors terminology as defined in STD62 rather than favoring 150 terminology that is consistent with non-SNMP specifications that use 151 different variations of the same terminology. This is consistent 152 with the IESG decision to not require the SNMPv3 terminology be 153 modified to match the usage of other non-SNMP specifications when 154 SNMPv3 was advanced to Full Standard. 156 Authentication in this document typically refers to the English 157 meaning of "serving to prove the authenticity of" the message, not 158 data source authentication or peer identity authentication. 160 The terms "manager" and "agent" are not used in this document, 161 because in the RFC 3411 architecture, all SNMP entities have the 162 capability of acting as either manager or agent or both depending on 163 the SNMP applications included in the engine. Where distinction is 164 required, the application names of Command Generator, Command 165 Responder, Notification Originator, Notification Receiver, and Proxy 166 Forwarder are used. See "SNMP Applications" [RFC3413] for further 167 information. 169 While security protocols frequently refer to a user, the terminology 170 used in RFC3411 [RFC3411] and in this memo is "principal". A 171 principal is the "who" on whose behalf services are provided or 172 processing takes place. A principal can be, among other things, an 173 individual acting in a particular role; a set of individuals, with 174 each acting in a particular role; an application or a set of 175 applications, or a combination of these within an administrative 176 domain. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 1.3. Modularity 184 The reader is expected to have read and understood the description of 185 the SNMP architecture, as defined in [RFC3411], and the architecture 186 extension specified in "Transport Subsystem for the Simple Network 187 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 188 external "lower layer transport" protocols to provide message 189 security, tied into the SNMP architecture through the Transport 190 Subsystem. The Transport Security Model is designed to work with 191 such lower-layer secure Transport Models. 193 In keeping with the RFC 3411 design decisions to use self-contained 194 documents, this memo includes the elements of procedure plus 195 associated MIB objects which are needed for processing the Transport 196 Security Model for SNMP. These MIB objects SHOULD NOT be referenced 197 in other documents. This allows the Transport Security Model to be 198 designed and documented as independent and self-contained, having no 199 direct impact on other modules, and allowing this module to be 200 upgraded and supplemented as the need arises, and to move along the 201 standards track on different time-lines from other modules. 203 This modularity of specification is not meant to be interpreted as 204 imposing any specific requirements on implementation. 206 1.4. Motivation 208 This memo describes a Security Model to make use of Transport Models 209 that use lower layer secure transports and existing and commonly 210 deployed security infrastructures. This Security Model is designed 211 to meet the security and operational needs of network administrators, 212 maximize usability in operational environments to achieve high 213 deployment success and at the same time minimize implementation and 214 deployment costs to minimize the time until deployment is possible. 216 1.5. Constraints 218 The design of this SNMP Security Model is also influenced by the 219 following constraints: 221 1. In times of network stress, the security protocol and its 222 underlying security mechanisms SHOULD NOT depend solely upon the 223 ready availability of other network services (e.g., Network Time 224 Protocol (NTP) or Authentication, Authorization, and Accounting 225 (AAA) protocols). 227 2. When the network is not under stress, the Security Model and its 228 underlying security mechanisms MAY depend upon the ready 229 availability of other network services. 231 3. It may not be possible for the Security Model to determine when 232 the network is under stress. 234 4. A Security Model should require no changes to the SNMP 235 architecture. 237 5. A Security Model should require no changes to the underlying 238 security protocol. 240 2. How the Transport Security Model Fits in the Architecture 242 The Transport Security Model is designed to fit into the RFC3411 243 architecture as a Security Model in the Security Subsystem, and to 244 utilize the services of a secure Transport Model. 246 For incoming messages, a secure Transport Model will pass a 247 tmStateReference cache, described later. To maintain RFC3411 248 modularity, the Transport Model will not know which securityModel 249 will process the incoming message; the Message Processing Model will 250 determine this. If the Transport Security Model is used with a non- 251 secure Transport Model, then the cache will not exist or not be 252 populated with security parameters, which will cause the Transport 253 Security Model to return an error (see section 5.2) 254 The Transport Security Model will create the securityName and 255 securityLevel to be passed to applications, and verify that the 256 tmTransportSecurityLevel reported by the Transport Model is at least 257 as strong as the securityLevel requested by the Message Processing 258 Model. 260 For outgoing messages, the Transport Security Model will create a 261 tmStateReference cache (or use an existing one), and pass the 262 tmStateReference to the specified Transport Model. 264 2.1. Security Capabilities of this Model 266 2.1.1. Threats 268 The Transport Security Model is compatible with the RFC3411 269 architecture, and provides protection against the threats identified 270 by the RFC 3411 architecture. However, the Transport Security Model 271 does not provide security mechanisms such as authentication and 272 encryption itself, so it SHOULD always be used with a Transport Model 273 that provides appropriate security. Which threats are addressed and 274 how they are mitigated depends on the Transport Model. 276 2.1.2. Security Levels 278 The RFC 3411 architecture recognizes three levels of security: 280 - without authentication and without privacy (noAuthNoPriv) 282 - with authentication but without privacy (authNoPriv) 284 - with authentication and with privacy (authPriv) 286 The model-independent securityLevel parameter is used to request 287 specific levels of security for outgoing messages, and to assert that 288 specific levels of security were applied during the transport and 289 processing of incoming messages. 291 The transport layer algorithms used to provide security SHOULD NOT be 292 exposed to the Transport Security Model, as the Transport Security 293 Model has no mechanisms by which it can test whether an assertion 294 made by a Transport Model is accurate. 296 The Transport Security Model trusts that the underlying secure 297 transport connection has been properly configured to support security 298 characteristics at least as strong as reported in 299 tmTransportSecurityLevel. 301 2.2. Transport Sessions 303 The Transport Security Model does not work with transport sessions 304 directly. Instead the transport-related state is associated with a 305 unique combination of transportDomain, transportAddress, securityName 306 and securityLevel, and referenced via the tmStateReference parameter. 307 How and if this is mapped to a particular transport or channel is the 308 responsibility of the Transport Subsystem. 310 2.3. Coexistence 312 In the RFC3411 architecture, a Message Processing Model determines 313 which Security Model should be called. As of this writing, IANA has 314 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 315 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 316 SNMPv2c, and the User-based Security Model). 318 2.3.1. Coexistence with Message Processing Models 320 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 321 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security 322 Models. Since there is no mechanism defined in RFC3584 to select an 323 alternative Security Model, SNMPv1 and SNMPv2c messages cannot use 324 the Transport Security Model. Such messages can still be conveyed 325 over a secure transport protocol, but the Transport Security Model 326 will not be invoked. 328 The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact 329 for which there is no existing IETF specification. 331 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 332 the securityModel from the msgSecurityModel field of an incoming 333 SNMPv3Message. When this value is transportSecurityModel(YY), 334 security processing is directed to the Transport Security Model. For 335 an outgoing message to be secured using the Transport Security Model, 336 the application should specify a securityModel parameter value of 337 transportSecurityModel(YY) in the sendPdu ASI. 339 [-- NOTE to RFC editor: replace YY with actual IANA-assigned number, 340 and remove this note. ] 342 2.3.2. Coexistence with Other Security Models 344 The Transport Security Model uses its own MIB module for processing 345 to maintain independence from other Security Models. This allows the 346 Transport Security Model to coexist with other Security Models, such 347 as the User-based Security Model [RFC3414]. 349 2.3.3. Coexistence with Transport Models 351 The Transport Security Model may work with multiple Transport Models, 352 but the RFC3411 application service interfaces (ASIs) do not carry a 353 value for the Transport Model. The MIB module defined in this memo 354 allows an administrator to configure whether or not TSM prepends a 355 transport model prefix to the securityName. This will allow SNMP 356 applications to consider transport model as a factor when making 357 decisions, such as access control, notification generation, and proxy 358 forwarding. 360 3. Cached Information and References 362 When performing SNMP processing, there are two levels of state 363 information that may need to be retained: the immediate state linking 364 a request-response pair, and potentially longer-term state relating 365 to transport and security. "Transport Subsystem for the Simple 366 Network Management Protocol" [I-D.ietf-isms-tmsm] defines general 367 requirements for caches and references. 369 This document defines additional cache requirements related to the 370 Transport Security Model. 372 3.1. Transport Security Model Cached Information 374 The Transport Security Model has specific responsibilities regarding 375 the cached information. 377 3.1.1. securityStateReference 379 The Transport Security Model adds the tmStateReference received from 380 the processIncomingMsg ASI to the securityStateReference. This 381 tmStateReference can then be retrieved during the generateResponseMsg 382 ASI, so that it can be passed back to the Transport Model. 384 3.1.2. tmStateReference 386 For outgoing messages, the Transport Security Model uses parameters 387 provided by the SNMP application to lookup or create a 388 tmStateReference. 390 The Transport Security Model REQUIRES that the security parameters 391 used for a response are the same as those used for the corresponding 392 request. This security model uses the tmStateReference stored as 393 part of the securityStateReference when appropriate. For responses 394 and reports, this security model sets the tmSameSecurity flag to true 395 in the tmStateReference before passing it to a transport model. 397 For incoming messages, the Transport Security Model uses parameters 398 provided in the tmStateReference cache to establish a securityName, 399 and to verify adequate security levels. 401 3.1.3. Prefixes and securityNames 403 The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module 404 [RFC3413], and other MIB modules contain objects to configure 405 security parameters for use by applications such as access control, 406 notification generation, and proxy forwarding. 408 IANA maintains a registry for transport domains and the corresponding 409 prefix. 411 If snmpTsmConfigurationUsePrefix is set to true then all 412 securityNames provided by, or provided to, the Transport Security 413 Model MUST include a valid transport domain prefix. 415 If snmpTsmConfigurationUsePrefix is set to false then all 416 securityNames provided by, or provided to, the Transport Security 417 Model MUST NOT include a transport domain prefix. 419 The tmSecurityName in the tmStateReference stored as part of the 420 securityStateReference does not contain a prefix. 422 4. Processing an Outgoing Message 424 An error indication may return an OID and value for an incremented 425 counter and a value for securityLevel, and values for contextEngineID 426 and contextName for the counter, and the securityStateReference if 427 the information is available at the point where the error is 428 detected. 430 4.1. Security Processing for an Outgoing Message 432 This section describes the procedure followed by the Transport 433 Security Model. 435 The parameters needed for generating a message are supplied to the 436 Security Model by the Message Processing Model via the 437 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 438 Subsystem architectural extension has added the transportDomain, 439 transportAddress, and tmStateReference parameters to the original 440 RFC3411 ASIs. 442 statusInformation = -- success or errorIndication 443 generateRequestMsg( 444 IN messageProcessingModel -- typically, SNMP version 445 IN globalData -- message header, admin data 446 IN maxMessageSize -- of the sending SNMP entity 447 IN transportDomain -- (NEW) specified by application 448 IN transportAddress -- (NEW) specified by application 449 IN securityModel -- for the outgoing message 450 IN securityEngineID -- authoritative SNMP entity 451 IN securityName -- on behalf of this principal 452 IN securityLevel -- Level of Security requested 453 IN scopedPDU -- message (plaintext) payload 454 OUT securityParameters -- filled in by Security Module 455 OUT wholeMsg -- complete generated message 456 OUT wholeMsgLength -- length of generated message 457 OUT tmStateReference -- (NEW) transport info 458 ) 460 statusInformation = -- success or errorIndication 461 generateResponseMsg( 462 IN messageProcessingModel -- typically, SNMP version 463 IN globalData -- message header, admin data 464 IN maxMessageSize -- of the sending SNMP entity 465 IN transportDomain -- (NEW) specified by application 466 IN transportAddress -- (NEW) specified by application 467 IN securityModel -- for the outgoing message 468 IN securityEngineID -- authoritative SNMP entity 469 IN securityName -- on behalf of this principal 470 IN securityLevel -- Level of Security requested 471 IN scopedPDU -- message (plaintext) payload 472 IN securityStateReference -- reference to security state 473 -- information from original 474 -- request 475 OUT securityParameters -- filled in by Security Module 476 OUT wholeMsg -- complete generated message 477 OUT wholeMsgLength -- length of generated message 478 OUT tmStateReference -- (NEW) transport info 479 ) 481 4.2. Elements of Procedure for Outgoing Messages 483 1) If there is a securityStateReference (Response or Report message), 484 then this security model uses the cached information rather than the 485 information provided by the ASI. Extract the tmStateReference from 486 the securityStateReference cache. Set the tmRequestedSecurityLevel 487 to the value of the extracted tmTransportSecurityLevel. Set the 488 tmSameSecurity parameter in the tmStateReference cache to true. The 489 cachedSecurityData for this message can now be discarded. 491 2) If there is no securityStateReference (e.g., a Request-type or 492 Notification message) then create a tmStateReference cache. Set 493 tmTransportDomain to the value of transportDomain, tmTransportAddress 494 to the value of transportAddress, and tmRequestedSecurityLevel to the 495 value of securityLevel. (Implementers might optimize by pointing to 496 saved copies of these session-specific values.) Set the transaction- 497 specific tmSameSecurity parameter to false. 499 If the snmpTsmConfigurationUsePrefix object is set to false, then set 500 tmSecurityName to the value of securityName. 502 If the snmpTsmConfigurationUsePrefix object is set to true, then use 503 the transportDomain to look up the corresponding prefix. (Since the 504 securityStateReference stores the tmStateReference with the 505 tmSecurityName for the incoming message, and tmSecurityName never has 506 a prefix, the prefix stripping step only occurs when we are not using 507 the securityStateReference). 509 If the prefix lookup fails for any reason, then the 510 snmpTsmUnknownPrefixes counter is incremented, an error indication 511 is returned to the calling module, and message processing stops. 513 If the lookup succeeds, but there is no prefix in the 514 securityName, or the prefix returned does not match the prefix in 515 the securityName, or the length of the prefix is less than 1 or 516 greater than four ASCII characters, then the 517 snmpTsmInvalidPrefixes counter is incremented, an error indication 518 is returned to the calling module, and message processing stops. 520 Strip the transport-specific prefix and trailing ':' character 521 (ASCII 0x3a) from the securityName. Set tmSecurityName to the 522 value of securityName. 524 3) Set securityParameters to a zero-length OCTET STRING ('0400'). 526 4) Combine the message parts into a wholeMsg and calculate 527 wholeMsgLength. 529 5) The wholeMsg, wholeMsgLength, securityParameters and 530 tmStateReference are returned to the calling Message Processing Model 531 with the statusInformation set to success. 533 5. Processing an Incoming SNMP Message 535 An error indication may return an OID and value for an incremented 536 counter and a value for securityLevel, and values for contextEngineID 537 and contextName for the counter, and the securityStateReference if 538 the information is available at the point where the error is 539 detected. 541 5.1. Security Processing for an Incoming Message 543 This section describes the procedure followed by the Transport 544 Security Model whenever it receives an incoming message from a 545 Message Processing Model. The ASI from a Message Processing Model to 546 the Security Subsystem for a received message is: 548 statusInformation = -- errorIndication or success 549 -- error counter OID/value if error 550 processIncomingMsg( 551 IN messageProcessingModel -- typically, SNMP version 552 IN maxMessageSize -- from the received message 553 IN securityParameters -- from the received message 554 IN securityModel -- from the received message 555 IN securityLevel -- from the received message 556 IN wholeMsg -- as received on the wire 557 IN wholeMsgLength -- length as received on the wire 558 IN tmStateReference -- (NEW) from the Transport Model 559 OUT securityEngineID -- authoritative SNMP entity 560 OUT securityName -- identification of the principal 561 OUT scopedPDU, -- message (plaintext) payload 562 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 563 OUT securityStateReference -- reference to security state 564 ) -- information, needed for response 566 5.2. Elements of Procedure for Incoming Messages 568 1) Set the securityEngineID to the local snmpEngineID. 570 2) If tmStateReference does not refer to a cache containing values 571 for tmTransportDomain, tmTransportAddress, tmSecurityName and 572 tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is 573 incremented, an error indication is returned to the calling module, 574 and Security Model processing stops for this message. 576 3) Copy the tmSecurityName to securityName. 578 If the snmpTsmConfigurationUsePrefix object is set to true, then use 579 the tmTransportDomain to look up the corresponding prefix. 581 If the prefix lookup fails for any reason, then the 582 snmpTsmUnknownPrefixes counter is incremented, an error indication 583 is returned to the calling module, and message processing stops. 585 If the lookup succeeds, but the prefix length is less than one or 586 greater than four octets, then the snmpTsmInvalidPrefixes counter 587 is incremented, an error indication is returned to the calling 588 module, and message processing stops. 590 Set the securityName to be the concatenation of the prefix, a ':' 591 character (ASCII 0x3a) and the tmSecurityName. 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, an error 601 indication (unsupportedSecurityLevel) together with the OID and value 602 of the incremented counter is returned to the calling module, and 603 Transport Security Model processing stops for this message. 605 5) The tmStateReference 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. 610 6) The scopedPDU component is extracted from the wholeMsg. 612 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 613 size allowed for a scopedPDU for a possible Response message. 615 8) The statusInformation is set to success and a return is made to 616 the calling module passing back the OUT parameters as specified in 617 the processIncomingMsg ASI. 619 6. MIB Module Overview 621 This MIB module provides objects for use only by the Transport 622 Security Model. It defines a configuration scalar and related error 623 counters. 625 6.1. Structure of the MIB Module 627 Objects in this MIB module are arranged into subtrees. Each subtree 628 is organized as a set of related objects. The overall structure and 629 assignment of objects to their subtrees, and the intended purpose of 630 each subtree, is shown below. 632 6.1.1. The snmpTsmStats Subtree 634 This subtree contains error counters specific to the Transport 635 Security Model. 637 6.1.2. The snmpTsmConfiguration Subtree 639 This subtree contains a configuration object that enables 640 administrators to specify if they want a transport domain prefix 641 prepended to securityNames for use by applications. 643 6.2. Relationship to Other MIB Modules 645 Some management objects defined in other MIB modules are applicable 646 to an entity implementing the Transport Security Model. In 647 particular, it is assumed that an entity implementing the Transport 648 Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the 649 SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and 650 the SNMPv2-MIB [RFC3418]. These are not needed to implement the 651 SNMP-TSM-MIB. 653 6.2.1. MIB Modules Required for IMPORTS 655 The following MIB module imports items from [RFC2578], [RFC2579], and 656 [RFC2580]. 658 7. MIB module definition 660 SNMP-TSM-MIB DEFINITIONS ::= BEGIN 662 IMPORTS 663 MODULE-IDENTITY, OBJECT-TYPE, 664 mib-2, Counter32 665 FROM SNMPv2-SMI 666 MODULE-COMPLIANCE, OBJECT-GROUP 667 FROM SNMPv2-CONF 668 TruthValue 669 FROM SNMPv2-TC 670 ; 672 snmpTsmMIB MODULE-IDENTITY 673 LAST-UPDATED "200903090000Z" 674 ORGANIZATION "ISMS Working Group" 675 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 676 Subscribe: isms-request@lists.ietf.org 678 Chairs: 680 Juergen Quittek 681 NEC Europe Ltd. 682 Network Laboratories 683 Kurfuersten-Anlage 36 684 69115 Heidelberg 685 Germany 686 +49 6221 90511-15 687 quittek@netlab.nec.de 689 Juergen Schoenwaelder 690 Jacobs University Bremen 691 Campus Ring 1 692 28725 Bremen 693 Germany 694 +49 421 200-3587 695 j.schoenwaelder@iu-bremen.de 697 Editor: 698 David Harrington 699 Huawei Technologies USA 700 1700 Alma Dr. 701 Plano TX 75075 702 USA 703 +1 603-436-8634 704 ietfdbh@comcast.net 706 Wes Hardaker 707 Sparta, Inc. 708 P.O. Box 382 709 Davis, CA 95617 710 USA 711 +1 530 792 1913 712 ietf@hardakers.net 713 " 714 DESCRIPTION "The Transport Security Model MIB 716 In keeping with the RFC 3411 design decisions 717 to use self-contained documents, the RFC which 718 contains the definition of this MIB module also 719 includes the elements of procedure which are 720 needed for processing the Transport Security 721 Model for SNMP. These MIB objects 722 SHOULD NOT be modified via other subsystems 723 or models defined in other document.. 724 This allows the Transport Security Model 725 for SNMP to be designed and documented as 726 independent and self- contained, having no 727 direct impact on other modules, and this 728 allows this module to be upgraded and 729 supplemented as the need arises, and to 730 move along the standards track on different 731 time-lines from other modules. 733 Copyright (c) 2009 IETF Trust and the persons identified as 734 authors of the MIB module. All rights reserved. 736 Redistribution and use in source and binary forms, with or without 737 modification, are permitted provided that the following conditions 738 are met: 739 - Redistributions of source code must retain the above copyright 740 notice, this list of conditions and the following disclaimer. 741 - Redistributions in binary form must reproduce the above 742 copyright notice, this list of conditions and the following 743 disclaimer in the documentation and/or other materials provided 744 with the distribution. 745 - Neither the name of Internet Society, IETF or IETF Trust, nor the 746 names of specific contributors, may be used to endorse or promote 747 products derived from this software without specific prior written 748 permission. 750 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 751 CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, 752 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 753 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 754 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 755 CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 756 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 757 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 758 USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 759 AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 760 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 761 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 762 POSSIBILITY OF SUCH DAMAGE. 764 This version of this MIB module is part of RFC XXXX; 765 see the RFC itself for full legal notices. 766 -- NOTE to RFC editor: replace XXXX with actual RFC number 767 -- for this document and remove this note 768 " 770 REVISION "200903090000Z" 771 DESCRIPTION "The initial version, published in RFC XXXX. 772 -- NOTE to RFC editor: replace XXXX with actual RFC number 773 -- for this document and remove this note 774 " 776 ::= { mib-2 xxxx } 777 -- RFC Ed.: replace xxxx with IANA-assigned number and 778 -- remove this note 780 -- ---------------------------------------------------------- -- 781 -- subtrees in the SNMP-TSM-MIB 782 -- ---------------------------------------------------------- -- 784 snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 } 785 snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 } 786 snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 } 788 -- ------------------------------------------------------------- 789 -- Objects 790 -- ------------------------------------------------------------- 792 -- Statistics for the Transport Security Model 794 snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 } 796 snmpTsmInvalidCaches OBJECT-TYPE 797 SYNTAX Counter32 798 MAX-ACCESS read-only 799 STATUS current 800 DESCRIPTION "The number of incoming messages dropped because the 801 tmStateReference referred to an invalid cache. 802 " 803 ::= { snmpTsmStats 1 } 805 snmpTsmInadequateSecurityLevels OBJECT-TYPE 806 SYNTAX Counter32 807 MAX-ACCESS read-only 808 STATUS current 809 DESCRIPTION "The number of incoming messages dropped because 810 the securityLevel asserted by the transport model was 811 less than the securityLevel requested by the 812 application. 813 " 814 ::= { snmpTsmStats 2 } 816 snmpTsmUnknownPrefixes OBJECT-TYPE 817 SYNTAX Counter32 818 MAX-ACCESS read-only 819 STATUS current 820 DESCRIPTION "The number of messages dropped because 821 snmpTsmConfigurationUsePrefix was set to true and 822 there is no known prefix for the specified transport 823 domain. 824 " 825 ::= { snmpTsmStats 3 } 827 snmpTsmInvalidPrefixes OBJECT-TYPE 828 SYNTAX Counter32 829 MAX-ACCESS read-only 830 STATUS current 831 DESCRIPTION "The number of messages dropped because 832 the securityName associated with an outgoing message 833 did not contain a valid transport domain prefix. 834 " 835 ::= { snmpTsmStats 4 } 837 -- ------------------------------------------------------------- 838 -- Configuration 839 -- ------------------------------------------------------------- 841 -- Configuration for the Transport Security Model 843 snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 } 845 snmpTsmConfigurationUsePrefix OBJECT-TYPE 846 SYNTAX TruthValue 847 MAX-ACCESS read-write 848 STATUS current 849 DESCRIPTION "If this object is set to true then securityNames 850 passing to and from the application are expected to 851 contain a transport domain specific prefix. If this 852 object is set to true then a domain specific prefix 853 will be added by the TSM to the securityName for 854 incoming messages and removed from the securityName 855 when processing outgoing messages. Transport domains 856 and prefixes are maintained in a registry by IANA. 857 This object SHOULD persist across system reboots. 858 " 859 DEFVAL { false } 860 ::= { snmpTsmConfiguration 1 } 862 -- ------------------------------------------------------------- 863 -- snmpTsmMIB - Conformance Information 864 -- ------------------------------------------------------------- 866 snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 } 868 snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 } 869 -- ------------------------------------------------------------- 870 -- Compliance statements 871 -- ------------------------------------------------------------- 873 snmpTsmCompliance MODULE-COMPLIANCE 874 STATUS current 875 DESCRIPTION "The compliance statement for SNMP engines that support 876 the SNMP-TSM-MIB 877 " 878 MODULE 879 MANDATORY-GROUPS { snmpTsmGroup } 880 ::= { snmpTsmCompliances 1 } 882 -- ------------------------------------------------------------- 883 -- Units of conformance 884 -- ------------------------------------------------------------- 885 snmpTsmGroup OBJECT-GROUP 886 OBJECTS { 887 snmpTsmInvalidCaches, 888 snmpTsmInadequateSecurityLevels, 889 snmpTsmUnknownPrefixes, 890 snmpTsmInvalidPrefixes, 891 snmpTsmConfigurationUsePrefix 892 } 893 STATUS current 894 DESCRIPTION "A collection of objects for maintaining 895 information of an SNMP engine which implements 896 the SNMP Transport Security Model. 897 " 899 ::= { snmpTsmGroups 2 } 901 END 903 8. Security Considerations 905 This document describes a Security Model, compatible with the RFC3411 906 architecture, that permits SNMP to utilize security services provided 907 through an SNMP Transport Model. The Transport Security Model relies 908 on Transport Models for mutual authentication, binding of keys, 909 confidentiality and integrity. 911 The Transport Security Model relies on secure Transport Models to 912 provide an authenticated principal identifier and an assertion of 913 whether authentication and privacy are used during transport. This 914 Security Model SHOULD always be used with Transport Models that 915 provide adequate security, but "adequate security" is a configuration 916 and/or run-time decision of the operator or management application. 917 The security threats and how these threats are mitigated should be 918 covered in detail in the specifications of the Transport Models and 919 the underlying secure transports. 921 An authenticated principal identifier (securityName) is used in SNMP 922 applications, for purposes such as access control, notification 923 generation, and proxy forwarding. This security model supports 924 multiple transport models. Operators might judge some transports to 925 be more secure than others, so this security model can be configured 926 to prepend a prefix to the securityName to indicate the transport 927 model used to authenticate the principal. Operators can use the 928 prefixed securityName when making application decisions about levels 929 of access. 931 8.1. MIB module security 933 There are a number of management objects defined in this MIB module 934 with a MAX-ACCESS clause of read-write and/or read-create. Such 935 objects may be considered sensitive or vulnerable in some network 936 environments. The support for SET operations in a non-secure 937 environment without proper protection can have a negative effect on 938 network operations. These are the tables and objects and their 939 sensitivity/vulnerability: 941 o The snmpTsmConfigurationUsePrefix object could be modified, 942 creating a denial of service or authorizing SNMP messages that 943 would not have previously been authorized by an Access Control 944 Model (e.g. the VACM). 946 Some of the readable objects in this MIB module (i.e., objects with a 947 MAX-ACCESS other than not-accessible) may be considered sensitive or 948 vulnerable in some network environments. It is thus important to 949 control even GET and/or NOTIFY access to these objects and possibly 950 to even encrypt the values of these objects when sending them over 951 the network via SNMP. These are the tables and objects and their 952 sensitivity/vulnerability: 954 o All the counters in this module refer to configuration errors and 955 do not expose sensitive information. 957 SNMP versions prior to SNMPv3 did not include adequate security. 958 Even if the network itself is secure (for example by using IPsec), 959 even then, there is no control as to who on the secure network is 960 allowed to access and GET/SET (read/change/create/delete) the objects 961 in this MIB module. 963 It is RECOMMENDED that implementers consider the security features as 964 provided by the SNMPv3 framework (see [RFC3410] section 8), including 965 full support for the USM and Transport Security Model cryptographic 966 mechanisms (for authentication and privacy). 968 Further, deployment of SNMP versions prior to SNMPv3 is NOT 969 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 970 enable cryptographic security. It is then a customer/operator 971 responsibility to ensure that the SNMP entity giving access to an 972 instance of this MIB module is properly configured to give access to 973 the objects only to those principals (users) that have legitimate 974 rights to indeed GET or SET (change/create/delete) them. 976 9. IANA Considerations 978 IANA is requested to assign: 980 1. an SMI number with a prefix of mib-2, in the MIB module registry 981 under http://www.iana.org/assignments/smi-numbers, for the MIB 982 module in this document, 984 2. a value, preferably 4, to identify the Transport Security Model, 985 in the Security Models registry at 986 http://www.iana.org/assignments/snmp-number-spaces. This should 987 result in the following table of values: 989 Value Description References 990 ----- ----------- ---------- 991 0 reserved for 'any' [RFC3411] 992 1 reserved for SNMPv1 [RFC3411] 993 2 reserved for SNMPv2c [RFC3411] 994 3 User-Based Security Model (USM) [RFC3411] 995 YY Transport Security Model (TSM) [RFCXXXX] 997 -- NOTE to RFC editor: replace XXXX with actual RFC number 998 -- for this document and remove this note 999 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 1000 throughout this document and remove this note. 1002 10. Acknowledgements 1004 The editors would like to thank Jeffrey Hutzelman for sharing his SSH 1005 insights, and Dave Shield for an outstanding job wordsmithing the 1006 existing document to improve organization and clarity. 1008 Additionally, helpful document reviews were received from: Juergen 1009 Schoenwaelder. 1011 11. References 1013 11.1. Normative References 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to 1016 Indicate Requirement Levels", BCP 14, RFC 2119, 1017 March 1997. 1019 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1020 Schoenwaelder, Ed., "Structure of Management 1021 Information Version 2 (SMIv2)", STD 58, 1022 RFC 2578, April 1999. 1024 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1025 Schoenwaelder, Ed., "Textual Conventions for 1026 SMIv2", STD 58, RFC 2579, April 1999. 1028 [RFC2580] McCloghrie, K., Perkins, D., and J. 1029 Schoenwaelder, "Conformance Statements for 1030 SMIv2", STD 58, RFC 2580, April 1999. 1032 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1033 Architecture for Describing Simple Network 1034 Management Protocol (SNMP) Management 1035 Frameworks", STD 62, RFC 3411, December 2002. 1037 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 1038 Wijnen, "Message Processing and Dispatching for 1039 the Simple Network Management Protocol (SNMP)", 1040 STD 62, RFC 3412, December 2002. 1042 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 1043 Network Management Protocol (SNMP) 1044 Applications", STD 62, RFC 3413, December 2002. 1046 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 1047 Security Model (USM) for version 3 of the 1048 Simple Network Management Protocol (SNMPv3)", 1049 STD 62, RFC 3414, December 2002. 1051 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 1052 Subsystem for the Simple Network Management 1053 Protocol (SNMP)", draft-ietf-isms-tmsm-16 (work 1054 in progress), February 2009. 1056 11.2. Informative References 1058 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1059 Stewart, "Introduction and Applicability 1060 Statements for Internet-Standard Management 1061 Framework", RFC 3410, December 2002. 1063 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, 1064 "View-based Access Control Model (VACM) for the 1065 Simple Network Management Protocol (SNMP)", 1066 STD 62, RFC 3415, December 2002. 1068 [RFC3418] Presuhn, R., "Management Information Base (MIB) 1069 for the Simple Network Management Protocol 1070 (SNMP)", STD 62, RFC 3418, December 2002. 1072 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 1073 Wijnen, "Coexistence between Version 1, Version 1074 2, and Version 3 of the Internet-standard 1075 Network Management Framework", BCP 74, 1076 RFC 3584, August 2003. 1078 Appendix A. Notification Tables Configuration 1080 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 1081 configure notification originators with the destinations to which 1082 notifications should be sent. 1084 Most of the configuration is security-model-independent and 1085 transport-model-independent. 1087 The values we will use in the examples for the five model-independent 1088 security and transport parameters are: 1090 transportDomain = snmpSSHDomain 1092 transportAddress = 192.0.2.1:PPP 1094 securityModel = Transport Security Model 1096 securityName = alice 1098 securityLevel = authPriv 1100 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1101 port number for SNMP notifications over SSH, from 1102 draft-ietf-isms-secshell, and remove this note. ] 1103 The following example will configure the Notification Originator to 1104 send informs to a Notification Receiver at 192.0.2.1:PPP using the 1105 securityName "alice". "alice" is the name for the recipient from the 1106 standpoint of the notification originator, and is used for processing 1107 access controls before sending a notification. 1109 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1110 port number for SNMP notifications over SSH, and remove this note. ] 1112 The columns marked with a "*" are the items that are Security Model 1113 or Transport Model specific. 1115 The configuration for the "alice" settings in the SNMP-VIEW-BASED- 1116 ACM-MIB objects are not shown here for brevity. First we configure 1117 which type of notification should be sent for this taglist (toCRTag). 1118 In this example, we choose to send an Inform. 1119 snmpNotifyTable row: 1120 snmpNotifyName CRNotif 1121 snmpNotifyTag toCRTag 1122 snmpNotifyType inform 1123 snmpNotifyStorageType nonVolatile 1124 snmpNotifyColumnStatus createAndGo 1126 Then we configure a transport address to which notifications 1127 associated with this taglist should be sent, and we specify which 1128 snmpTargetParamsEntry should be used (toCR) when sending to this 1129 transport address. 1130 snmpTargetAddrTable row: 1131 snmpTargetAddrName toCRAddr 1132 * snmpTargetAddrTDomain snmpSSHDomain 1133 * snmpTargetAddrTAddress 192.0.2.1:PPP 1134 snmpTargetAddrTimeout 1500 1135 snmpTargetAddrRetryCount 3 1136 snmpTargetAddrTagList toCRTag 1137 snmpTargetAddrParams toCR (must match below) 1138 snmpTargetAddrStorageType nonVolatile 1139 snmpTargetAddrColumnStatus createAndGo 1141 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1142 port number for SNMP notifications over SSH, and remove this note. ] 1144 Then we configure which principal at the host should receive the 1145 notifications associated with this taglist. Here we choose "alice", 1146 who uses the Transport Security Model. 1148 snmpTargetParamsTable row: 1149 snmpTargetParamsName toCR 1150 snmpTargetParamsMPModel SNMPv3 1151 * snmpTargetParamsSecurityModel TransportSecurityModel 1152 snmpTargetParamsSecurityName "alice" 1153 snmpTargetParamsSecurityLevel authPriv 1154 snmpTargetParamsStorageType nonVolatile 1155 snmpTargetParamsRowStatus createAndGo 1157 A.1. Transport Security Model Processing for Notifications 1159 The Transport Security Model is called using the generateRequestMsg() 1160 ASI, with the following parameters (* are from the above tables): 1162 statusInformation = -- success or errorIndication 1163 generateRequestMsg( 1164 IN messageProcessingModel -- *snmpTargetParamsMPModel 1165 IN globalData -- message header, admin data 1166 IN maxMessageSize -- of the sending SNMP entity 1167 IN transportDomain -- *snmpTargetAddrTDomain 1168 IN transportAddress -- *snmpTargetAddrTAddress 1169 IN securityModel -- *snmpTargetParamsSecurityModel 1170 IN securityEngineID -- immaterial; TSM will ignore. 1171 IN securityName -- snmpTargetParamsSecurityName 1172 IN securityLevel -- *snmpTargetParamsSecurityLevel 1173 IN scopedPDU -- message (plaintext) payload 1174 OUT securityParameters -- filled in by Security Module 1175 OUT wholeMsg -- complete generated message 1176 OUT wholeMsgLength -- length of generated message 1177 OUT tmStateReference -- reference to transport info 1178 ) 1180 The Transport Security Model will determine the Transport Model based 1181 on the snmpTargetAddrTDomain. The selected Transport Model will 1182 select the appropriate transport connection using the 1183 tmStateReference cache created from the values of 1184 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1185 snmpTargetParamsSecurityLevel. 1187 Appendix B. Processing Differences between USM and Secure Transport 1189 USM and secure transports differ in the processing order and 1190 responsibilities within the RFC3411 architecture. While the steps 1191 are the same, they occur in a different order, and may be done by 1192 different subsystems. The following lists illustrate the difference 1193 in the flow and the responsibility for different processing steps for 1194 incoming messages when using USM and when using a secure transport. 1196 (These lists are simplified for illustrative purposes, and do not 1197 represent all details of processing. Transport Models must provide 1198 the detailed elements of procedure.) 1200 With USM, SNMPv1, and SNMPv2c Security Models, security processing 1201 starts when the Message Processing Model decodes portions of the 1202 ASN.1 message to extract header fields that are used to determine 1203 which Security Model should process the message to perform 1204 authentication, decryption, timeliness checking, integrity checking, 1205 and translation of parameters to model-independent parameters. By 1206 comparison, a secure transport performs those security functions on 1207 the message, before the ASN.1 is decoded. 1209 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 1210 are the same for USM and a secure transport. 1212 B.1. USM and the RFC3411 Architecture 1214 1) decode the ASN.1 header (Message Processing Model) 1216 2) determine the SNMP Security Model and parameters (Message 1217 Processing Model) 1219 3) verify securityLevel. [Security Model] 1221 4) translate parameters to model-independent parameters (Security 1222 Model) 1224 5) authenticate the principal, check message integrity and 1225 timeliness, and decrypt the message. [Security Model] 1227 6) determine the pduType in the decrypted portions (Message 1228 Processing Model), and 1230 7) pass on the decrypted portions with model-independent parameters. 1232 B.2. Transport Subsystem and the RFC3411 Architecture 1234 1) authenticate the principal, check integrity and timeliness of the 1235 message, and decrypt the message. [Transport Model] 1237 2) translate parameters to model-independent parameters (Transport 1238 Model) 1240 3) decode the ASN.1 header (Message Processing Model) 1241 4) determine the SNMP Security Model and parameters (Message 1242 Processing Model) 1244 5) verify securityLevel [Security Model] 1246 6) determine the pduType in the decrypted portions (Message 1247 Processing Model), and 1249 7) pass on the decrypted portions with model-independent security 1250 parameters 1252 If a message is secured using a secure transport layer, then the 1253 Transport Model should provide the translation from the authenticated 1254 identity (e.g., an SSH user name) to a human-friendly identifier 1255 (tmSecurityName) in step 2. The security model will provide a 1256 mapping from that identifier to a model-independent securityName. 1258 Authors' Addresses 1260 David Harrington 1261 Huawei Technologies (USA) 1262 1700 Alma Dr. Suite 100 1263 Plano, TX 75075 1264 USA 1266 Phone: +1 603 436 8634 1267 EMail: dharrington@huawei.com 1269 Wes Hardaker 1270 Sparta, Inc. 1271 P.O. Box 382 1272 Davis, CA 95617 1273 US 1275 Phone: +1 530 792 1913 1276 EMail: ietf@hardakers.net