idnits 2.17.1 draft-ietf-isms-transport-security-model-14.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 1184 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 (May 6, 2009) is 5466 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 1016, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-17 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' == Outdated reference: A later version (-18) exists of draft-ietf-isms-secshell-16 Summary: 1 error (**), 0 flaws (~~), 6 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: November 7, 2009 Sparta, Inc. 6 May 6, 2009 8 Transport Security Model for SNMP 9 draft-ietf-isms-transport-security-model-14 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 November 7, 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 . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10 85 3.1.3. Prefixes and securityNames . . . . . . . . . . . . . . 10 86 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 87 4.1. Security Processing for an Outgoing Message . . . . . . . 11 88 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 12 89 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 13 90 5.1. Security Processing for an Incoming Message . . . . . . . 13 91 5.2. Elements of Procedure for Incoming Messages . . . . . . . 14 92 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 15 93 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 15 94 6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 15 95 6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 15 96 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 16 97 6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 16 98 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 16 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 22 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 106 Appendix A. Notification Tables Configuration . . . . . . . . . . 25 107 A.1. Transport Security Model Processing for Notifications . . 27 108 Appendix B. Processing Differences between USM and Secure 109 Transport . . . . . . . . . . . . . . . . . . . . . . 27 110 B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 28 111 B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 28 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 needed, 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 Non uppercased versions of the keywords should be read as in normal 183 English. They will usually, but not always, be used in a context 184 relating to compatibility with the RFC3411 architecture or the 185 subsystem defined here, but which might have no impact on on-the-wire 186 compatibility. These terms are used as guidance for designers of 187 proposed IETF models to make the designs compatible with RFC3411 188 subsystems and Abstract Service Interfaces (ASIs) (see section 3.2). 189 Implementers are free to implement differently. Some usages of these 190 lowercase terms are simply normal English usage. 192 1.3. Modularity 194 The reader is expected to have read and understood the description of 195 the SNMP architecture, as defined in [RFC3411], and the architecture 196 extension specified in "Transport Subsystem for the Simple Network 197 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 198 external "lower layer transport" protocols to provide message 199 security, tied into the SNMP architecture through the Transport 200 Subsystem. The Transport Security Model is designed to work with 201 such lower-layer secure Transport Models. 203 In keeping with the RFC 3411 design decisions to use self-contained 204 documents, this memo includes the elements of procedure plus 205 associated MIB objects which are needed for processing the Transport 206 Security Model for SNMP. These MIB objects SHOULD NOT be referenced 207 in other documents. This allows the Transport Security Model to be 208 designed and documented as independent and self-contained, having no 209 direct impact on other modules, and allowing this module to be 210 upgraded and supplemented as the need arises, and to move along the 211 standards track on different time-lines from other modules. 213 This modularity of specification is not meant to be interpreted as 214 imposing any specific requirements on implementation. 216 1.4. Motivation 218 This memo describes a Security Model to make use of Transport Models 219 that use lower layer secure transports and existing and commonly 220 deployed security infrastructures. This Security Model is designed 221 to meet the security and operational needs of network administrators, 222 maximize usability in operational environments to achieve high 223 deployment success and at the same time minimize implementation and 224 deployment costs to minimize the time until deployment is possible. 226 1.5. Constraints 228 The design of this SNMP Security Model is also influenced by the 229 following constraints: 231 1. In times of network stress, the security protocol and its 232 underlying security mechanisms SHOULD NOT depend solely upon the 233 ready availability of other network services (e.g., Network Time 234 Protocol (NTP) or Authentication, Authorization, and Accounting 235 (AAA) protocols). 237 2. When the network is not under stress, the Security Model and its 238 underlying security mechanisms MAY depend upon the ready 239 availability of other network services. 241 3. It might not be possible for the Security Model to determine when 242 the network is under stress. 244 4. A Security Model SHOULD NOT require changes to the SNMP 245 architecture. 247 5. A Security Model SHOULD NOT require changes to the underlying 248 security protocol. 250 2. How the Transport Security Model Fits in the Architecture 252 The Transport Security Model is designed to fit into the RFC3411 253 architecture as a Security Model in the Security Subsystem, and to 254 utilize the services of a secure Transport Model. 256 For incoming messages, a secure Transport Model will pass a 257 tmStateReference cache, described later. To maintain RFC3411 258 modularity, the Transport Model will not know which securityModel 259 will process the incoming message; the Message Processing Model will 260 determine this. If the Transport Security Model is used with a non- 261 secure Transport Model, then the cache will not exist or not be 262 populated with security parameters, which will cause the Transport 263 Security Model to return an error (see section 5.2) 265 The Transport Security Model will create the securityName and 266 securityLevel to be passed to applications, and verify that the 267 tmTransportSecurityLevel reported by the Transport Model is at least 268 as strong as the securityLevel requested by the Message Processing 269 Model. 271 For outgoing messages, the Transport Security Model will create a 272 tmStateReference cache (or use an existing one), and pass the 273 tmStateReference to the specified Transport Model. 275 2.1. Security Capabilities of this Model 277 2.1.1. Threats 279 The Transport Security Model is compatible with the RFC3411 280 architecture, and provides protection against the threats identified 281 by the RFC 3411 architecture. However, the Transport Security Model 282 does not provide security mechanisms such as authentication and 283 encryption itself. Which threats are addressed and how they are 284 mitigated depends on the Transport Model used. To avoid creating 285 potential security vulnerabilities, operators should configure their 286 system so this Security Model is always used with a Transport Model 287 that provides appropriate security, where "appropriate" for a 288 particular deployment is an administrative decision. 290 2.1.2. Security Levels 292 The RFC 3411 architecture recognizes three levels of security: 294 - without authentication and without privacy (noAuthNoPriv) 296 - with authentication but without privacy (authNoPriv) 298 - with authentication and with privacy (authPriv) 300 The model-independent securityLevel parameter is used to request 301 specific levels of security for outgoing messages, and to assert that 302 specific levels of security were applied during the transport and 303 processing of incoming messages. 305 The transport layer algorithms used to provide security should not be 306 exposed to the Transport Security Model, as the Transport Security 307 Model has no mechanisms by which it can test whether an assertion 308 made by a Transport Model is accurate. 310 The Transport Security Model trusts that the underlying secure 311 transport connection has been properly configured to support security 312 characteristics at least as strong as reported in 313 tmTransportSecurityLevel. 315 2.2. Transport Sessions 317 The Transport Security Model does not work with transport sessions 318 directly. Instead the transport-related state is associated with a 319 unique combination of transportDomain, transportAddress, securityName 320 and securityLevel, and referenced via the tmStateReference parameter. 321 How and if this is mapped to a particular transport or channel is the 322 responsibility of the Transport Subsystem. 324 2.3. Coexistence 326 In the RFC3411 architecture, a Message Processing Model determines 327 which Security Model SHALL be called. As of this writing, IANA has 328 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 329 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 330 SNMPv2c, and the User-based Security Model). 332 2.3.1. Coexistence with Message Processing Models 334 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 335 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security 336 Models. Since there is no mechanism defined in RFC3584 to select an 337 alternative Security Model, SNMPv1 and SNMPv2c messages cannot use 338 the Transport Security Model. Messages might still be able to be 339 conveyed over a secure transport protocol, but the Transport Security 340 Model will not be invoked. 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 this value is transportSecurityModel(YY), 348 security processing is directed to the Transport Security Model. For 349 an outgoing message to be secured using the Transport Security Model, 350 the application MUST specify a securityModel parameter value of 351 transportSecurityModel(YY) in the sendPdu Application Service 352 Interface (ASI). 354 [-- NOTE to RFC editor: replace YY with actual IANA-assigned number, 355 and remove this note. ] 357 2.3.2. Coexistence with Other Security Models 359 The Transport Security Model uses its own MIB module for processing 360 to maintain independence from other Security Models. This allows the 361 Transport Security Model to coexist with other Security Models, such 362 as the User-based Security Model [RFC3414]. 364 2.3.3. Coexistence with Transport Models 366 The Transport Security Model MAY work with multiple Transport Models, 367 but the RFC3411 application service interfaces (ASIs) do not carry a 368 value for the Transport Model. The MIB module defined in this memo 369 allows an administrator to configure whether or not TSM prepends a 370 transport model prefix to the securityName. This will allow SNMP 371 applications to consider transport model as a factor when making 372 decisions, such as access control, notification generation, and proxy 373 forwarding. 375 To have SNMP properly utilize the security services coordinated by 376 the Transport Security Model, this Security Model MUST only be used 377 with Transport Models that know how to process a tmStateReference, 378 such as the Secure Shell Transport Model [I-D.ietf-isms-secshell]. 380 3. Cached Information and References 382 When performing SNMP processing, there are two levels of state 383 information that might need to be retained: the immediate state 384 linking a request-response pair, and potentially longer-term state 385 relating to transport and security. "Transport Subsystem for the 386 Simple Network Management Protocol" [I-D.ietf-isms-tmsm] defines 387 general requirements for caches and references. 389 This document defines additional cache requirements related to the 390 Transport Security Model. 392 3.1. Transport Security Model Cached Information 394 The Transport Security Model has specific responsibilities regarding 395 the cached information. 397 3.1.1. securityStateReference 399 The Transport Security Model adds the tmStateReference received from 400 the processIncomingMsg ASI to the securityStateReference. This 401 tmStateReference can then be retrieved during the generateResponseMsg 402 ASI, so that it can be passed back to the Transport Model. 404 3.1.2. tmStateReference 406 For outgoing messages, the Transport Security Model uses parameters 407 provided by the SNMP application to lookup or create a 408 tmStateReference. 410 For the Transport Security Model, the security parameters used for a 411 response MUST be the same as those used for the corresponding 412 request. This security model uses the tmStateReference stored as 413 part of the securityStateReference when appropriate. For responses 414 and reports, this security model sets the tmSameSecurity flag to true 415 in the tmStateReference before passing it to a transport model. 417 For incoming messages, the Transport Security Model uses parameters 418 provided in the tmStateReference cache to establish a securityName, 419 and to verify adequate security levels. 421 3.1.3. Prefixes and securityNames 423 The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module 424 [RFC3413], and other MIB modules contain objects to configure 425 security parameters for use by applications such as access control, 426 notification generation, and proxy forwarding. 428 Transport domains and their corresponding prefixes are coordinated 429 via the IANA registry "SNMP Transport Domains". 431 If snmpTsmConfigurationUsePrefix is set to true then all 432 securityNames provided by, or provided to, the Transport Security 433 Model MUST include a valid transport domain prefix. 435 If snmpTsmConfigurationUsePrefix is set to false then all 436 securityNames provided by, or provided to, the Transport Security 437 Model MUST NOT include a transport domain prefix. 439 The tmSecurityName in the tmStateReference stored as part of the 440 securityStateReference does not contain a prefix. 442 4. Processing an Outgoing Message 444 An error indication might return an OID and value for an incremented 445 counter and a value for securityLevel, and values for contextEngineID 446 and contextName for the counter, and the securityStateReference if 447 the information is available at the point where the error is 448 detected. 450 4.1. Security Processing for an Outgoing Message 452 This section describes the procedure followed by the Transport 453 Security Model. 455 The parameters needed for generating a message are supplied to the 456 Security Model by the Message Processing Model via the 457 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 458 Subsystem architectural extension has added the transportDomain, 459 transportAddress, and tmStateReference parameters to the original 460 RFC3411 ASIs. 462 statusInformation = -- success or errorIndication 463 generateRequestMsg( 464 IN messageProcessingModel -- typically, SNMP version 465 IN globalData -- message header, admin data 466 IN maxMessageSize -- of the sending SNMP entity 467 IN transportDomain -- (NEW) specified by application 468 IN transportAddress -- (NEW) specified by application 469 IN securityModel -- for the outgoing message 470 IN securityEngineID -- authoritative SNMP entity 471 IN securityName -- on behalf of this principal 472 IN securityLevel -- Level of Security requested 473 IN scopedPDU -- message (plaintext) payload 474 OUT securityParameters -- filled in by Security Module 475 OUT wholeMsg -- complete generated message 476 OUT wholeMsgLength -- length of generated message 477 OUT tmStateReference -- (NEW) transport info 478 ) 480 statusInformation = -- success or errorIndication 481 generateResponseMsg( 482 IN messageProcessingModel -- typically, SNMP version 483 IN globalData -- message header, admin data 484 IN maxMessageSize -- of the sending SNMP entity 485 IN transportDomain -- (NEW) specified by application 486 IN transportAddress -- (NEW) specified by application 487 IN securityModel -- for the outgoing message 488 IN securityEngineID -- authoritative SNMP entity 489 IN securityName -- on behalf of this principal 490 IN securityLevel -- Level of Security requested 491 IN scopedPDU -- message (plaintext) payload 492 IN securityStateReference -- reference to security state 493 -- information from original 494 -- request 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 4.2. Elements of Procedure for Outgoing Messages 503 1) If there is a securityStateReference (Response or Report message), 504 then this security model uses the cached information rather than the 505 information provided by the ASI. Extract the tmStateReference from 506 the securityStateReference cache. Set the tmRequestedSecurityLevel 507 to the value of the extracted tmTransportSecurityLevel. Set the 508 tmSameSecurity parameter in the tmStateReference cache to true. The 509 cachedSecurityData for this message can now be discarded. 511 2) If there is no securityStateReference (e.g., a Request-type or 512 Notification message) then create a tmStateReference cache. Set 513 tmTransportDomain to the value of transportDomain, tmTransportAddress 514 to the value of transportAddress, and tmRequestedSecurityLevel to the 515 value of securityLevel. (Implementers might optimize by pointing to 516 saved copies of these session-specific values.) Set the transaction- 517 specific tmSameSecurity parameter to false. 519 If the snmpTsmConfigurationUsePrefix object is set to false, then set 520 tmSecurityName to the value of securityName. 522 If the snmpTsmConfigurationUsePrefix object is set to true, then use 523 the transportDomain to look up the corresponding prefix. (Since the 524 securityStateReference stores the tmStateReference with the 525 tmSecurityName for the incoming message, and tmSecurityName never has 526 a prefix, the prefix stripping step only occurs when we are not using 527 the securityStateReference). 529 If the prefix lookup fails for any reason, then the 530 snmpTsmUnknownPrefixes counter is incremented, an error indication 531 is returned to the calling module, and message processing stops. 533 If the lookup succeeds, but there is no prefix in the 534 securityName, or the prefix returned does not match the prefix in 535 the securityName, or the length of the prefix is less than 1 or 536 greater than four US-ASCII alpha-numeric characters, then the 537 snmpTsmInvalidPrefixes counter is incremented, an error indication 538 is returned to the calling module, and message processing stops. 540 Strip the transport-specific prefix and trailing ':' character 541 (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the 542 value of securityName. 544 3) Set securityParameters to a zero-length OCTET STRING ('0400'). 546 4) Combine the message parts into a wholeMsg and calculate 547 wholeMsgLength. 549 5) The wholeMsg, wholeMsgLength, securityParameters and 550 tmStateReference are returned to the calling Message Processing Model 551 with the statusInformation set to success. 553 5. Processing an Incoming SNMP Message 555 An error indication might return an OID and value for an incremented 556 counter and a value for securityLevel, and values for contextEngineID 557 and contextName for the counter, and the securityStateReference if 558 the information is available at the point where the error is 559 detected. 561 5.1. Security Processing for an Incoming Message 563 This section describes the procedure followed by the Transport 564 Security Model whenever it receives an incoming message from a 565 Message Processing Model. The ASI from a Message Processing Model to 566 the Security Subsystem for a received message is: 568 statusInformation = -- errorIndication or success 569 -- error counter OID/value if error 570 processIncomingMsg( 571 IN messageProcessingModel -- typically, SNMP version 572 IN maxMessageSize -- from the received message 573 IN securityParameters -- from the received message 574 IN securityModel -- from the received message 575 IN securityLevel -- from the received message 576 IN wholeMsg -- as received on the wire 577 IN wholeMsgLength -- length as received on the wire 578 IN tmStateReference -- (NEW) from the Transport Model 579 OUT securityEngineID -- authoritative SNMP entity 580 OUT securityName -- identification of the principal 581 OUT scopedPDU, -- message (plaintext) payload 582 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 583 OUT securityStateReference -- reference to security state 584 ) -- information, needed for response 586 5.2. Elements of Procedure for Incoming Messages 588 1) Set the securityEngineID to the local snmpEngineID. 590 2) If tmStateReference does not refer to a cache containing values 591 for tmTransportDomain, tmTransportAddress, tmSecurityName and 592 tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is 593 incremented, an error indication is returned to the calling module, 594 and Security Model processing stops for this message. 596 3) Copy the tmSecurityName to securityName. 598 If the snmpTsmConfigurationUsePrefix object is set to true, then use 599 the tmTransportDomain to look up the corresponding prefix. 601 If the prefix lookup fails for any reason, then the 602 snmpTsmUnknownPrefixes counter is incremented, an error indication 603 is returned to the calling module, and message processing stops. 605 If the lookup succeeds, but the prefix length is less than one or 606 greater than four octets, then the snmpTsmInvalidPrefixes counter 607 is incremented, an error indication is returned to the calling 608 module, and message processing stops. 610 Set the securityName to be the concatenation of the prefix, a ':' 611 character (US-ASCII 0x3a) and the tmSecurityName. 613 4) Compare the value of tmTransportSecurityLevel in the 614 tmStateReference cache to the value of the securityLevel parameter 615 passed in the processIncomingMsg ASI. If securityLevel specifies 616 privacy (Priv), and tmTransportSecurityLevel specifies no privacy 617 (noPriv), or securityLevel specifies authentication (auth) and 618 tmTransportSecurityLevel specifies no authentication (noAuth) was 619 provided by the Transport Model, then the 620 snmpTsmInadequateSecurityLevels counter is incremented, an error 621 indication (unsupportedSecurityLevel) together with the OID and value 622 of the incremented counter is returned to the calling module, and 623 Transport Security Model processing stops for this message. 625 5) The tmStateReference is cached as cachedSecurityData, so that a 626 possible response to this message will use the same security 627 parameters. Then securityStateReference is set for subsequent 628 reference to this cached data. 630 6) The scopedPDU component is extracted from the wholeMsg. 632 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 633 size allowed for a scopedPDU for a possible Response message. 635 8) The statusInformation is set to success and a return is made to 636 the calling module passing back the OUT parameters as specified in 637 the processIncomingMsg ASI. 639 6. MIB Module Overview 641 This MIB module provides objects for use only by the Transport 642 Security Model. It defines a configuration scalar and related error 643 counters. 645 6.1. Structure of the MIB Module 647 Objects in this MIB module are arranged into subtrees. Each subtree 648 is organized as a set of related objects. The overall structure and 649 assignment of objects to their subtrees, and the intended purpose of 650 each subtree, is shown below. 652 6.1.1. The snmpTsmStats Subtree 654 This subtree contains error counters specific to the Transport 655 Security Model. 657 6.1.2. The snmpTsmConfiguration Subtree 659 This subtree contains a configuration object that enables 660 administrators to specify if they want a transport domain prefix 661 prepended to securityNames for use by applications. 663 6.2. Relationship to Other MIB Modules 665 Some management objects defined in other MIB modules are applicable 666 to an entity implementing the Transport Security Model. In 667 particular, it is assumed that an entity implementing the Transport 668 Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the 669 SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and 670 the SNMPv2-MIB [RFC3418]. These are not needed to implement the 671 SNMP-TSM-MIB. 673 6.2.1. MIB Modules Required for IMPORTS 675 The following MIB module imports items from [RFC2578], [RFC2579], and 676 [RFC2580]. 678 7. MIB module definition 680 SNMP-TSM-MIB DEFINITIONS ::= BEGIN 682 IMPORTS 683 MODULE-IDENTITY, OBJECT-TYPE, 684 mib-2, Counter32 685 FROM SNMPv2-SMI -- RFC2578 686 MODULE-COMPLIANCE, OBJECT-GROUP 687 FROM SNMPv2-CONF -- RFC2580 688 TruthValue 689 FROM SNMPv2-TC -- RFC2579 690 ; 692 snmpTsmMIB MODULE-IDENTITY 693 LAST-UPDATED "200903090000Z" 694 ORGANIZATION "ISMS Working Group" 695 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 696 Subscribe: isms-request@lists.ietf.org 698 Chairs: 699 Juergen Quittek 700 NEC Europe Ltd. 701 Network Laboratories 702 Kurfuersten-Anlage 36 703 69115 Heidelberg 704 Germany 705 +49 6221 90511-15 706 quittek@netlab.nec.de 708 Juergen Schoenwaelder 709 Jacobs University Bremen 710 Campus Ring 1 711 28725 Bremen 712 Germany 713 +49 421 200-3587 714 j.schoenwaelder@iu-bremen.de 716 Editor: 717 David Harrington 718 Huawei Technologies USA 719 1700 Alma Dr. 720 Plano TX 75075 721 USA 722 +1 603-436-8634 723 ietfdbh@comcast.net 725 Wes Hardaker 726 Sparta, Inc. 727 P.O. Box 382 728 Davis, CA 95617 729 USA 730 +1 530 792 1913 731 ietf@hardakers.net 732 " 733 DESCRIPTION "The Transport Security Model MIB 735 In keeping with the RFC 3411 design decisions 736 to use self-contained documents, the RFC which 737 contains the definition of this MIB module also 738 includes the elements of procedure which are 739 needed for processing the Transport Security 740 Model for SNMP. These MIB objects 741 SHOULD NOT be modified via other subsystems 742 or models defined in other documents. 743 This allows the Transport Security Model 744 for SNMP to be designed and documented as 745 independent and self- contained, having no 746 direct impact on other modules, and this 747 allows this module to be upgraded and 748 supplemented as the need arises, and to 749 move along the standards track on different 750 time-lines from other modules. 752 Copyright (c) 2009 IETF Trust and the persons identified as 753 authors of the MIB module. All rights reserved. 755 Redistribution and use in source and binary forms, with or without 756 modification, are permitted provided that the following conditions 757 are met: 759 - Redistributions of source code must retain the above copyright 760 notice, this list of conditions and the following disclaimer. 761 - Redistributions in binary form must reproduce the above 762 copyright notice, this list of conditions and the following 763 disclaimer in the documentation and/or other materials provided 764 with the distribution. 765 - Neither the name of Internet Society, IETF or IETF Trust, nor the 766 names of specific contributors, may be used to endorse or promote 767 products derived from this software without specific prior written 768 permission. 770 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 771 CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, 772 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 773 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 774 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 775 CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 776 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 777 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 778 USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 779 AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 780 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 781 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 782 POSSIBILITY OF SUCH DAMAGE. 784 This version of this MIB module is part of RFC XXXX; 785 see the RFC itself for full legal notices. 786 -- NOTE to RFC editor: replace XXXX with actual RFC number 787 -- for this document and remove this note 788 " 790 REVISION "200903090000Z" 791 DESCRIPTION "The initial version, published in RFC XXXX. 792 -- NOTE to RFC editor: replace XXXX with actual RFC number 793 -- for this document and remove this note 794 " 796 ::= { mib-2 xxxx } 797 -- RFC Ed.: replace xxxx with IANA-assigned number and 798 -- remove this note 800 -- ---------------------------------------------------------- -- 801 -- subtrees in the SNMP-TSM-MIB 802 -- ---------------------------------------------------------- -- 804 snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 } 805 snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 } 806 snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 } 807 -- ------------------------------------------------------------- 808 -- Objects 809 -- ------------------------------------------------------------- 811 -- Statistics for the Transport Security Model 813 snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 } 815 snmpTsmInvalidCaches OBJECT-TYPE 816 SYNTAX Counter32 817 MAX-ACCESS read-only 818 STATUS current 819 DESCRIPTION "The number of incoming messages dropped because the 820 tmStateReference referred to an invalid cache. 821 " 822 ::= { snmpTsmStats 1 } 824 snmpTsmInadequateSecurityLevels OBJECT-TYPE 825 SYNTAX Counter32 826 MAX-ACCESS read-only 827 STATUS current 828 DESCRIPTION "The number of incoming messages dropped because 829 the securityLevel asserted by the transport model was 830 less than the securityLevel requested by the 831 application. 832 " 833 ::= { snmpTsmStats 2 } 835 snmpTsmUnknownPrefixes OBJECT-TYPE 836 SYNTAX Counter32 837 MAX-ACCESS read-only 838 STATUS current 839 DESCRIPTION "The number of messages dropped because 840 snmpTsmConfigurationUsePrefix was set to true and 841 there is no known prefix for the specified transport 842 domain. 843 " 844 ::= { snmpTsmStats 3 } 846 snmpTsmInvalidPrefixes OBJECT-TYPE 847 SYNTAX Counter32 848 MAX-ACCESS read-only 849 STATUS current 850 DESCRIPTION "The number of messages dropped because 851 the securityName associated with an outgoing message 852 did not contain a valid transport domain prefix. 853 " 855 ::= { snmpTsmStats 4 } 857 -- ------------------------------------------------------------- 858 -- Configuration 859 -- ------------------------------------------------------------- 861 -- Configuration for the Transport Security Model 863 snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 } 865 snmpTsmConfigurationUsePrefix OBJECT-TYPE 866 SYNTAX TruthValue 867 MAX-ACCESS read-write 868 STATUS current 869 DESCRIPTION "If this object is set to true then securityNames 870 passing to and from the application are expected to 871 contain a transport domain specific prefix. If this 872 object is set to true then a domain specific prefix 873 will be added by the TSM to the securityName for 874 incoming messages and removed from the securityName 875 when processing outgoing messages. Transport domains 876 and prefixes are maintained in a registry by IANA. 877 This object SHOULD persist across system reboots. 878 " 879 DEFVAL { false } 880 ::= { snmpTsmConfiguration 1 } 882 -- ------------------------------------------------------------- 883 -- snmpTsmMIB - Conformance Information 884 -- ------------------------------------------------------------- 886 snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 } 888 snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 } 890 -- ------------------------------------------------------------- 891 -- Compliance statements 892 -- ------------------------------------------------------------- 894 snmpTsmCompliance MODULE-COMPLIANCE 895 STATUS current 896 DESCRIPTION "The compliance statement for SNMP engines that support 897 the SNMP-TSM-MIB 898 " 899 MODULE 900 MANDATORY-GROUPS { snmpTsmGroup } 901 ::= { snmpTsmCompliances 1 } 903 -- ------------------------------------------------------------- 904 -- Units of conformance 905 -- ------------------------------------------------------------- 906 snmpTsmGroup OBJECT-GROUP 907 OBJECTS { 908 snmpTsmInvalidCaches, 909 snmpTsmInadequateSecurityLevels, 910 snmpTsmUnknownPrefixes, 911 snmpTsmInvalidPrefixes, 912 snmpTsmConfigurationUsePrefix 913 } 914 STATUS current 915 DESCRIPTION "A collection of objects for maintaining 916 information of an SNMP engine which implements 917 the SNMP Transport Security Model. 918 " 920 ::= { snmpTsmGroups 2 } 922 END 924 8. Security Considerations 926 This document describes a Security Model, compatible with the RFC3411 927 architecture, that permits SNMP to utilize security services provided 928 through an SNMP Transport Model. The Transport Security Model relies 929 on Transport Models for mutual authentication, binding of keys, 930 confidentiality and integrity. 932 The Transport Security Model relies on secure Transport Models to 933 provide an authenticated principal identifier and an assertion of 934 whether authentication and privacy are used during transport. This 935 Security Model SHOULD always be used with Transport Models that 936 provide adequate security, but "adequate security" is a configuration 937 and/or run-time decision of the operator or management application. 938 The security threats and how these threats are mitigated should be 939 covered in detail in the specifications of the Transport Models and 940 the underlying secure transports. 942 An authenticated principal identifier (securityName) is used in SNMP 943 applications, for purposes such as access control, notification 944 generation, and proxy forwarding. This security model supports 945 multiple transport models. Operators might judge some transports to 946 be more secure than others, so this security model can be configured 947 to prepend a prefix to the securityName to indicate the transport 948 model used to authenticate the principal. Operators can use the 949 prefixed securityName when making application decisions about levels 950 of access. 952 8.1. MIB module security 954 There are a number of management objects defined in this MIB module 955 with a MAX-ACCESS clause of read-write and/or read-create. Such 956 objects may be considered sensitive or vulnerable in some network 957 environments. The support for SET operations in a non-secure 958 environment without proper protection can have a negative effect on 959 network operations. These are the tables and objects and their 960 sensitivity/vulnerability: 962 o The snmpTsmConfigurationUsePrefix object could be modified, 963 creating a denial of service or authorizing SNMP messages that 964 would not have previously been authorized by an Access Control 965 Model (e.g. the VACM). 967 Some of the readable objects in this MIB module (i.e., objects with a 968 MAX-ACCESS other than not-accessible) may be considered sensitive or 969 vulnerable in some network environments. It is thus important to 970 control even GET and/or NOTIFY access to these objects and possibly 971 to even encrypt the values of these objects when sending them over 972 the network via SNMP. These are the tables and objects and their 973 sensitivity/vulnerability: 975 o All the counters in this module refer to configuration errors and 976 do not expose sensitive information. 978 SNMP versions prior to SNMPv3 did not include adequate security. 979 Even if the network itself is secure (for example by using IPsec), 980 even then, there is no control as to who on the secure network is 981 allowed to access and GET/SET (read/change/create/delete) the objects 982 in this MIB module. 984 It is RECOMMENDED that implementers consider the security features as 985 provided by the SNMPv3 framework (see [RFC3410] section 8), including 986 full support for the USM and Transport Security Model cryptographic 987 mechanisms (for authentication and privacy). 989 Further, deployment of SNMP versions prior to SNMPv3 is NOT 990 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 991 enable cryptographic security. It is then a customer/operator 992 responsibility to ensure that the SNMP entity giving access to an 993 instance of this MIB module is properly configured to give access to 994 the objects only to those principals (users) that have legitimate 995 rights to indeed GET or SET (change/create/delete) them. 997 9. IANA Considerations 999 IANA is requested to assign: 1001 1. an SMI number with a prefix of mib-2, in the MIB module registry 1002 under http://www.iana.org/assignments/smi-numbers, for the MIB 1003 module in this document, 1005 2. a value, preferably 4, to identify the Transport Security Model, 1006 in the Security Models registry at 1007 http://www.iana.org/assignments/snmp-number-spaces. This should 1008 result in the following table of values: 1010 Value Description References 1011 ----- ----------- ---------- 1012 0 reserved for 'any' [RFC3411] 1013 1 reserved for SNMPv1 [RFC3411] 1014 2 reserved for SNMPv2c [RFC3411] 1015 3 User-Based Security Model (USM) [RFC3411] 1016 YY Transport Security Model (TSM) [RFCXXXX] 1018 -- NOTE to RFC editor: replace XXXX with actual RFC number 1019 -- for this document and remove this note 1020 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 1021 throughout this document and remove this note. 1023 10. Acknowledgements 1025 The editors would like to thank Jeffrey Hutzelman for sharing his SSH 1026 insights, and Dave Shield for an outstanding job wordsmithing the 1027 existing document to improve organization and clarity. 1029 Additionally, helpful document reviews were received from: Juergen 1030 Schoenwaelder. 1032 11. References 1034 11.1. Normative References 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to 1037 Indicate Requirement Levels", BCP 14, 1038 RFC 2119, March 1997. 1040 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and 1041 J. Schoenwaelder, Ed., "Structure of 1042 Management Information Version 2 (SMIv2)", 1043 STD 58, RFC 2578, April 1999. 1045 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and 1046 J. Schoenwaelder, Ed., "Textual Conventions 1047 for SMIv2", STD 58, RFC 2579, April 1999. 1049 [RFC2580] McCloghrie, K., Perkins, D., and J. 1050 Schoenwaelder, "Conformance Statements for 1051 SMIv2", STD 58, RFC 2580, April 1999. 1053 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, 1054 "An Architecture for Describing Simple 1055 Network Management Protocol (SNMP) 1056 Management Frameworks", STD 62, RFC 3411, 1057 December 2002. 1059 [RFC3412] Case, J., Harrington, D., Presuhn, R., and 1060 B. Wijnen, "Message Processing and 1061 Dispatching for the Simple Network 1062 Management Protocol (SNMP)", STD 62, 1063 RFC 3412, December 2002. 1065 [RFC3413] Levi, D., Meyer, P., and B. Stewart, 1066 "Simple Network Management Protocol (SNMP) 1067 Applications", STD 62, RFC 3413, 1068 December 2002. 1070 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 1071 Security Model (USM) for version 3 of the 1072 Simple Network Management Protocol 1073 (SNMPv3)", STD 62, RFC 3414, December 2002. 1075 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, 1076 "Transport Subsystem for the Simple Network 1077 Management Protocol (SNMP)", 1078 draft-ietf-isms-tmsm-17 (work in progress), 1079 April 2009. 1081 11.2. Informative References 1083 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1084 Stewart, "Introduction and Applicability 1085 Statements for Internet-Standard Management 1086 Framework", RFC 3410, December 2002. 1088 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, 1089 "View-based Access Control Model (VACM) for 1090 the Simple Network Management Protocol 1091 (SNMP)", STD 62, RFC 3415, December 2002. 1093 [RFC3418] Presuhn, R., "Management Information Base 1094 (MIB) for the Simple Network Management 1095 Protocol (SNMP)", STD 62, RFC 3418, 1096 December 2002. 1098 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 1099 Wijnen, "Coexistence between Version 1, 1100 Version 2, and Version 3 of the Internet- 1101 standard Network Management Framework", 1102 BCP 74, RFC 3584, August 2003. 1104 [I-D.ietf-isms-secshell] Harrington, D., Salowey, J., and W. 1105 Hardaker, "Secure Shell Transport Model for 1106 SNMP", draft-ietf-isms-secshell-16 (work in 1107 progress), April 2009. 1109 Appendix A. Notification Tables Configuration 1111 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 1112 configure notification originators with the destinations to which 1113 notifications should be sent. 1115 Most of the configuration is security-model-independent and 1116 transport-model-independent. 1118 The values we will use in the examples for the five model-independent 1119 security and transport parameters are: 1121 transportDomain = snmpSSHDomain 1123 transportAddress = 192.0.2.1:PPP 1125 securityModel = Transport Security Model 1127 securityName = alice 1129 securityLevel = authPriv 1131 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1132 port number for SNMP notifications over SSH, from 1133 draft-ietf-isms-secshell, and remove this note. ] 1135 The following example will configure the Notification Originator to 1136 send informs to a Notification Receiver at 192.0.2.1:PPP using the 1137 securityName "alice". "alice" is the name for the recipient from the 1138 standpoint of the notification originator, and is used for processing 1139 access controls before sending a notification. 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 The columns marked with a "*" are the items that are Security Model 1145 or Transport Model specific. 1147 The configuration for the "alice" settings in the SNMP-VIEW-BASED- 1148 ACM-MIB objects are not shown here for brevity. First we configure 1149 which type of notification will be sent for this taglist (toCRTag). 1150 In this example, we choose to send an Inform. 1151 snmpNotifyTable row: 1152 snmpNotifyName CRNotif 1153 snmpNotifyTag toCRTag 1154 snmpNotifyType inform 1155 snmpNotifyStorageType nonVolatile 1156 snmpNotifyColumnStatus createAndGo 1158 Then we configure a transport address to which notifications 1159 associated with this taglist will be sent, and we specify which 1160 snmpTargetParamsEntry will be used (toCR) when sending to this 1161 transport address. 1162 snmpTargetAddrTable row: 1163 snmpTargetAddrName toCRAddr 1164 * snmpTargetAddrTDomain snmpSSHDomain 1165 * snmpTargetAddrTAddress 192.0.2.1:PPP 1166 snmpTargetAddrTimeout 1500 1167 snmpTargetAddrRetryCount 3 1168 snmpTargetAddrTagList toCRTag 1169 snmpTargetAddrParams toCR (MUST match below) 1170 snmpTargetAddrStorageType nonVolatile 1171 snmpTargetAddrColumnStatus createAndGo 1173 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1174 port number for SNMP notifications over SSH, and remove this note. ] 1176 Then we configure which principal at the host will receive the 1177 notifications associated with this taglist. Here we choose "alice", 1178 who uses the Transport Security Model. 1179 snmpTargetParamsTable row: 1180 snmpTargetParamsName toCR 1181 snmpTargetParamsMPModel SNMPv3 1182 * snmpTargetParamsSecurityModel TransportSecurityModel 1183 snmpTargetParamsSecurityName "alice" 1184 snmpTargetParamsSecurityLevel authPriv 1185 snmpTargetParamsStorageType nonVolatile 1186 snmpTargetParamsRowStatus createAndGo 1188 A.1. Transport Security Model Processing for Notifications 1190 The Transport Security Model is called using the generateRequestMsg() 1191 ASI, with the following parameters (* are from the above tables): 1193 statusInformation = -- success or errorIndication 1194 generateRequestMsg( 1195 IN messageProcessingModel -- *snmpTargetParamsMPModel 1196 IN globalData -- message header, admin data 1197 IN maxMessageSize -- of the sending SNMP entity 1198 IN transportDomain -- *snmpTargetAddrTDomain 1199 IN transportAddress -- *snmpTargetAddrTAddress 1200 IN securityModel -- *snmpTargetParamsSecurityModel 1201 IN securityEngineID -- immaterial; TSM will ignore. 1202 IN securityName -- snmpTargetParamsSecurityName 1203 IN securityLevel -- *snmpTargetParamsSecurityLevel 1204 IN scopedPDU -- message (plaintext) payload 1205 OUT securityParameters -- filled in by Security Module 1206 OUT wholeMsg -- complete generated message 1207 OUT wholeMsgLength -- length of generated message 1208 OUT tmStateReference -- reference to transport info 1209 ) 1211 The Transport Security Model will determine the Transport Model based 1212 on the snmpTargetAddrTDomain. The selected Transport Model will 1213 select the appropriate transport connection using the 1214 tmStateReference cache created from the values of 1215 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1216 snmpTargetParamsSecurityLevel. 1218 Appendix B. Processing Differences between USM and Secure Transport 1220 USM and secure transports differ in the processing order and 1221 responsibilities within the RFC3411 architecture. While the steps 1222 are the same, they occur in a different order, and might be done by 1223 different subsystems. The following lists illustrate the difference 1224 in the flow and the responsibility for different processing steps for 1225 incoming messages when using USM and when using a secure transport. 1226 (These lists are simplified for illustrative purposes, and do not 1227 represent all details of processing. Transport Models MUST provide 1228 the detailed elements of procedure.) 1230 With USM, SNMPv1, and SNMPv2c Security Models, security processing 1231 starts when the Message Processing Model decodes portions of the 1232 ASN.1 message to extract header fields that are used to determine 1233 which Security Model will process the message to perform 1234 authentication, decryption, timeliness checking, integrity checking, 1235 and translation of parameters to model-independent parameters. By 1236 comparison, a secure transport performs those security functions on 1237 the message, before the ASN.1 is decoded. 1239 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 1240 are the same for USM and a secure transport. 1242 B.1. USM and the RFC3411 Architecture 1244 1) decode the ASN.1 header (Message Processing Model) 1246 2) determine the SNMP Security Model and parameters (Message 1247 Processing Model) 1249 3) verify securityLevel. [Security Model] 1251 4) translate parameters to model-independent parameters (Security 1252 Model) 1254 5) authenticate the principal, check message integrity and 1255 timeliness, and decrypt the message. [Security Model] 1257 6) determine the pduType in the decrypted portions (Message 1258 Processing Model), and 1260 7) pass on the decrypted portions with model-independent parameters. 1262 B.2. Transport Subsystem and the RFC3411 Architecture 1264 1) authenticate the principal, check integrity and timeliness of the 1265 message, and decrypt the message. [Transport Model] 1267 2) translate parameters to model-independent parameters (Transport 1268 Model) 1270 3) decode the ASN.1 header (Message Processing Model) 1272 4) determine the SNMP Security Model and parameters (Message 1273 Processing Model) 1275 5) verify securityLevel [Security Model] 1277 6) determine the pduType in the decrypted portions (Message 1278 Processing Model), and 1280 7) pass on the decrypted portions with model-independent security 1281 parameters 1283 If a message is secured using a secure transport layer, then the 1284 Transport Model will provide the translation from the authenticated 1285 identity (e.g., an SSH user name) to a human-friendly identifier 1286 (tmSecurityName) in step 2. The security model will provide a 1287 mapping from that identifier to a model-independent securityName. 1289 Authors' Addresses 1291 David Harrington 1292 Huawei Technologies (USA) 1293 1700 Alma Dr. Suite 100 1294 Plano, TX 75075 1295 USA 1297 Phone: +1 603 436 8634 1298 EMail: dharrington@huawei.com 1300 Wes Hardaker 1301 Sparta, Inc. 1302 P.O. Box 382 1303 Davis, CA 95617 1304 US 1306 Phone: +1 530 792 1913 1307 EMail: ietf@hardakers.net