idnits 2.17.1 draft-ietf-isms-transport-security-model-12.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 1119 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 (March 9, 2009) is 5524 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 966, 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: September 10, 2009 Sparta, Inc. 6 March 9, 2009 8 Transport Security Model for SNMP 9 draft-ietf-isms-transport-security-model-12 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 September 10, 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 . . . . . . . . . . . . . . . . . . . 20 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 106 Appendix A. Notification Tables Configuration . . . . . . . . . . 23 107 A.1. Transport Security Model Processing for Notifications . . 25 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 112 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 28 113 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 28 115 1. Introduction 117 This memo describes a Transport Security Model for the Simple Network 118 Management Protocol, for use with secure Transport Models in the 119 Transport Subsystem [I-D.ietf-isms-tmsm]. 121 This memo also defines a portion of the Management Information Base 122 (MIB) for monitoring and managing the Transport Security Model for 123 SNMP. 125 It is important to understand the SNMP architecture and the 126 terminology of the architecture to understand where the Transport 127 Security Model described in this memo fits into the architecture and 128 interacts with other subsystems and models within the architecture. 129 It is expected that reader will have also read and understood RFC3411 130 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 131 [RFC3418]. 133 1.1. The Internet-Standard Management Framework 135 For a detailed overview of the documents that describe the current 136 Internet-Standard Management Framework, please refer to section 7 of 137 RFC 3410 [RFC3410]. 139 Managed objects are accessed via a virtual information store, termed 140 the Management Information Base or MIB. MIB objects are generally 141 accessed through the Simple Network Management Protocol (SNMP). 142 Objects in the MIB are defined using the mechanisms defined in the 143 Structure of Management Information (SMI). This memo specifies a MIB 144 module that is compliant to the SMIv2, which is described in STD 58, 145 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 146 [RFC2580]. 148 1.2. Conventions 150 For consistency with SNMP-related specifications, this document 151 favors terminology as defined in STD62 rather than favoring 152 terminology that is consistent with non-SNMP specifications that use 153 different variations of the same terminology. This is consistent 154 with the IESG decision to not require the SNMPv3 terminology be 155 modified to match the usage of other non-SNMP specifications when 156 SNMPv3 was advanced to Full Standard. 158 Authentication in this document typically refers to the English 159 meaning of "serving to prove the authenticity of" the message, not 160 data source authentication or peer identity authentication. 162 The terms "manager" and "agent" are not used in this document, 163 because in the RFC 3411 architecture, all SNMP entities have the 164 capability of acting as either manager or agent or both depending on 165 the SNMP applications included in the engine. Where distinction is 166 required, the application names of Command Generator, Command 167 Responder, Notification Originator, Notification Receiver, and Proxy 168 Forwarder are used. See "SNMP Applications" [RFC3413] for further 169 information. 171 While security protocols frequently refer to a user, the terminology 172 used in RFC3411 [RFC3411] and in this memo is "principal". A 173 principal is the "who" on whose behalf services are provided or 174 processing takes place. A principal can be, among other things, an 175 individual acting in a particular role; a set of individuals, with 176 each acting in a particular role; an application or a set of 177 applications, or a combination of these within an administrative 178 domain. 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 1.3. Modularity 186 The reader is expected to have read and understood the description of 187 the SNMP architecture, as defined in [RFC3411], and the architecture 188 extension specified in "Transport Subsystem for the Simple Network 189 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 190 external "lower layer transport" protocols to provide message 191 security, tied into the SNMP architecture through the Transport 192 Subsystem. The Transport Security Model is designed to work with 193 such lower-layer secure Transport Models. 195 In keeping with the RFC 3411 design decisions to use self-contained 196 documents, this memo includes the elements of procedure plus 197 associated MIB objects which are needed for processing the Transport 198 Security Model for SNMP. These MIB objects SHOULD NOT be referenced 199 in other documents. This allows the Transport Security Model to be 200 designed and documented as independent and self-contained, having no 201 direct impact on other modules, and allowing this module to be 202 upgraded and supplemented as the need arises, and to move along the 203 standards track on different time-lines from other modules. 205 This modularity of specification is not meant to be interpreted as 206 imposing any specific requirements on implementation. 208 1.4. Motivation 210 This memo describes a Security Model to make use of Transport Models 211 that use lower layer secure transports and existing and commonly 212 deployed security infrastructures. This Security Model is designed 213 to meet the security and operational needs of network administrators, 214 maximize usability in operational environments to achieve high 215 deployment success and at the same time minimize implementation and 216 deployment costs to minimize the time until deployment is possible. 218 1.5. Constraints 220 The design of this SNMP Security Model is also influenced by the 221 following constraints: 223 1. In times of network stress, the security protocol and its 224 underlying security mechanisms SHOULD NOT depend solely upon the 225 ready availability of other network services (e.g., Network Time 226 Protocol (NTP) or Authentication, Authorization, and Accounting 227 (AAA) protocols). 229 2. When the network is not under stress, the Security Model and its 230 underlying security mechanisms MAY depend upon the ready 231 availability of other network services. 233 3. It may not be possible for the Security Model to determine when 234 the network is under stress. 236 4. A Security Model should require no changes to the SNMP 237 architecture. 239 5. A Security Model should require no changes to the underlying 240 security protocol. 242 2. How the Transport Security Model Fits in the Architecture 244 The Transport Security Model is designed to fit into the RFC3411 245 architecture as a Security Model in the Security Subsystem, and to 246 utilize the services of a secure Transport Model. 248 For incoming messages, a secure Transport Model will pass a 249 tmStateReference cache, described later. To maintain RFC3411 250 modularity, the Transport Model will not know which securityModel 251 will process the incoming message; the Message Processing Model will 252 determine this. If the Transport Security Model is used with a non- 253 secure Transport Model, then the cache will not exist or not be 254 populated with security parameters, which will cause the Transport 255 Security Model to return an error (see section 5.2) 256 The Transport Security Model will create the securityName and 257 securityLevel to be passed to applications, and verify that the 258 tmTransportSecurityLevel reported by the Transport Model is at least 259 as strong as the securityLevel requested by the Message Processing 260 Model. 262 For outgoing messages, the Transport Security Model will create a 263 tmStateReference cache (or use an existing one), and pass the 264 tmStateReference to the specified Transport Model. 266 2.1. Security Capabilities of this Model 268 2.1.1. Threats 270 The Transport Security Model is compatible with the RFC3411 271 architecture, and provides protection against the threats identified 272 by the RFC 3411 architecture. However, the Transport Security Model 273 does not provide security mechanisms such as authentication and 274 encryption itself, so it SHOULD always be used with a Transport Model 275 that provides appropriate security. Which threats are addressed and 276 how they are mitigated depends on the Transport Model. 278 2.1.2. Security Levels 280 The RFC 3411 architecture recognizes three levels of security: 282 - without authentication and without privacy (noAuthNoPriv) 284 - with authentication but without privacy (authNoPriv) 286 - with authentication and with privacy (authPriv) 288 The model-independent securityLevel parameter is used to request 289 specific levels of security for outgoing messages, and to assert that 290 specific levels of security were applied during the transport and 291 processing of incoming messages. 293 The transport layer algorithms used to provide security SHOULD NOT be 294 exposed to the Transport Security Model, as the Transport Security 295 Model has no mechanisms by which it can test whether an assertion 296 made by a Transport Model is accurate. 298 The Transport Security Model trusts that the underlying secure 299 transport connection has been properly configured to support security 300 characteristics at least as strong as reported in 301 tmTransportSecurityLevel. 303 2.2. Transport Sessions 305 The Transport Security Model does not work with transport sessions 306 directly. Instead the transport-related state is associated with a 307 unique combination of transportDomain, transportAddress, securityName 308 and securityLevel, and referenced via the tmStateReference parameter. 309 How and if this is mapped to a particular transport or channel is the 310 responsibility of the Transport Subsystem. 312 2.3. Coexistence 314 In the RFC3411 architecture, a Message Processing Model determines 315 which Security Model should be called. As of this writing, IANA has 316 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 317 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 318 SNMPv2c, and the User-based Security Model). 320 2.3.1. Coexistence with Message Processing Models 322 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 323 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security 324 Models. Since there is no mechanism defined in RFC3584 to select an 325 alternative Security Model, SNMPv1 and SNMPv2c messages cannot use 326 the Transport Security Model. Such messages can still be conveyed 327 over a secure transport protocol, but the Transport Security Model 328 will not be invoked. 330 The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact 331 for which there is no existing IETF specification. 333 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 334 the securityModel from the msgSecurityModel field of an incoming 335 SNMPv3Message. When this value is transportSecurityModel(YY), 336 security processing is directed to the Transport Security Model. For 337 an outgoing message to be secured using the Transport Security Model, 338 the application should specify a securityModel parameter value of 339 transportSecurityModel(YY) in the sendPdu ASI. 341 [-- NOTE to RFC editor: replace YY with actual IANA-assigned number, 342 and remove this note. ] 344 2.3.2. Coexistence with Other Security Models 346 The Transport Security Model uses its own MIB module for processing 347 to maintain independence from other Security Models. This allows the 348 Transport Security Model to coexist with other Security Models, such 349 as the User-based Security Model. 351 2.3.3. Coexistence with Transport Models 353 The Transport Security Model may work with multiple Transport Models, 354 but the RFC3411 application service interfaces (ASIs) do not carry a 355 value for the Transport Model. The MIB module defined in this memo 356 allows an administrator to configure whether or not TSM prepends a 357 transport model prefix to the securityName. This will allow SNMP 358 applications to consider transport model as a factor when making 359 decisions, such as access control, notification generation, and proxy 360 forwarding. 362 3. Cached Information and References 364 When performing SNMP processing, there are two levels of state 365 information that may need to be retained: the immediate state linking 366 a request-response pair, and potentially longer-term state relating 367 to transport and security. "Transport Subsystem for the Simple 368 Network Management Protocol" [I-D.ietf-isms-tmsm] defines general 369 requirements for caches and references. 371 This document defines additional cache requirements related to the 372 Transport Security Model. 374 3.1. Transport Security Model Cached Information 376 The Transport Security Model has specific responsibilities regarding 377 the cached information. 379 3.1.1. securityStateReference 381 The Transport Security Model adds the tmStateReference received from 382 the processIncomingMsg ASI to the securityStateReference. This 383 tmStateReference can then be retrieved during the generateResponseMsg 384 ASI, so that it can be passed back to the Transport Model. 386 3.1.2. tmStateReference 388 For outgoing messages, the Transport Security Model uses parameters 389 provided by the SNMP application to lookup or create a 390 tmStateReference. 392 The Transport Security Model REQUIRES that the security parameters 393 used for a response are the same as those used for the corresponding 394 request. This security model uses the tmStateReference stored as 395 part of the securityStateReference when appropriate. For responses 396 and reports, this security model sets the tmSameSecurity flag to true 397 in the tmStateReference before passing it to a transport model. 399 For incoming messages, the Transport Security Model uses parameters 400 provided in the tmStateReference cache to establish a securityName, 401 and to verify adequate security levels. 403 3.1.3. Prefixes and securityNames 405 The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module 406 [RFC3413], and other MIB modules contain objects to configure 407 security parameters for use by applications such as access control, 408 notification generation, and proxy forwarding. 410 IANA maintains a registry for transport domains and the corresponding 411 prefix. 413 If snmpTsmConfigurationUsePrefix is set to true then all 414 securityNames provided by, or provided to, the Transport Security 415 Model MUST include a valid transport domain prefix. 417 If snmpTsmConfigurationUsePrefix is set to false then all 418 securityNames provided by, or provided to, the Transport Security 419 Model MUST NOT include a transport domain prefix. 421 The tmSecurityName in the tmStateReference stored as part of the 422 securityStateReference does not contain a prefix. 424 4. Processing an Outgoing Message 426 An error indication may return an OID and value for an incremented 427 counter and a value for securityLevel, and values for contextEngineID 428 and contextName for the counter, and the securityStateReference if 429 the information is available at the point where the error is 430 detected. 432 4.1. Security Processing for an Outgoing Message 434 This section describes the procedure followed by the Transport 435 Security Model. 437 The parameters needed for generating a message are supplied to the 438 Security Model by the Message Processing Model via the 439 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 440 Subsystem architectural extension has added the transportDomain, 441 transportAddress, and tmStateReference parameters to the original 442 RFC3411 ASIs. 444 statusInformation = -- success or errorIndication 445 generateRequestMsg( 446 IN messageProcessingModel -- typically, SNMP version 447 IN globalData -- message header, admin data 448 IN maxMessageSize -- of the sending SNMP entity 449 IN transportDomain -- (NEW) specified by application 450 IN transportAddress -- (NEW) specified by application 451 IN securityModel -- for the outgoing message 452 IN securityEngineID -- authoritative SNMP entity 453 IN securityName -- on behalf of this principal 454 IN securityLevel -- Level of Security requested 455 IN scopedPDU -- message (plaintext) payload 456 OUT securityParameters -- filled in by Security Module 457 OUT wholeMsg -- complete generated message 458 OUT wholeMsgLength -- length of generated message 459 OUT tmStateReference -- (NEW) transport info 460 ) 462 statusInformation = -- success or errorIndication 463 generateResponseMsg( 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 IN securityStateReference -- reference to security state 475 -- information from original 476 -- request 477 OUT securityParameters -- filled in by Security Module 478 OUT wholeMsg -- complete generated message 479 OUT wholeMsgLength -- length of generated message 480 OUT tmStateReference -- (NEW) transport info 481 ) 483 4.2. Elements of Procedure for Outgoing Messages 485 1) If there is a securityStateReference (Response or Report message), 486 then this security model uses the cached information rather than the 487 information provided by the ASI. Extract the tmStateReference from 488 the securityStateReference cache. Set the tmRequestedSecurityLevel 489 to the value of the extracted tmTransportSecurityLevel. Set the 490 tmSameSecurity parameter in the tmStateReference cache to true. The 491 cachedSecurityData for this message can now be discarded. 493 2) If there is no securityStateReference (e.g., a Request-type or 494 Notification message) then create a tmStateReference cache. Set 495 tmTransportDomain to the value of transportDomain, tmTransportAddress 496 to the value of transportAddress, and tmRequestedSecurityLevel to the 497 value of securityLevel. (Implementers might optimize by pointing to 498 saved copies of these session-specific values.) Set the transaction- 499 specific tmSameSecurity parameter to false. 501 If the snmpTsmConfigurationUsePrefix object is set to false, then set 502 tmSecurityName to the value of securityName. 504 If the snmpTsmConfigurationUsePrefix object is set to true, then use 505 the transportDomain to look up the corresponding prefix. (Since the 506 securityStateReference stores the tmStateReference with the 507 tmSecurityName for the incoming message, and tmSecurityName never has 508 a prefix, the prefix stripping step only occurs when we are not using 509 the securityStateReference). 511 If the prefix lookup fails for any reason, then the 512 snmpTsmUnknownPrefixes counter is incremented, an error indication 513 is returned to the calling module, and message processing stops. 515 If the lookup succeeds, but there is no prefix in the 516 securityName, or the prefix returned does not match the prefix in 517 the securityName, or the length of the prefix is less than 1 or 518 greater than four ASCII characters, then the 519 snmpTsmInvalidPrefixes counter is incremented, an error indication 520 is returned to the calling module, and message processing stops. 522 Strip the transport-specific prefix and trailing ':' character 523 (ASCII 0x3a) from the securityName. Set tmSecurityName to the 524 value of securityName. 526 3) Set securityParameters to a zero-length OCTET STRING ('0400'). 528 4) Combine the message parts into a wholeMsg and calculate 529 wholeMsgLength. 531 5) The wholeMsg, wholeMsgLength, securityParameters and 532 tmStateReference are returned to the calling Message Processing Model 533 with the statusInformation set to success. 535 5. Processing an Incoming SNMP Message 537 An error indication may return an OID and value for an incremented 538 counter and a value for securityLevel, and values for contextEngineID 539 and contextName for the counter, and the securityStateReference if 540 the information is available at the point where the error is 541 detected. 543 5.1. Security Processing for an Incoming Message 545 This section describes the procedure followed by the Transport 546 Security Model whenever it receives an incoming message from a 547 Message Processing Model. The ASI from a Message Processing Model to 548 the Security Subsystem for a received message is: 550 statusInformation = -- errorIndication or success 551 -- error counter OID/value if error 552 processIncomingMsg( 553 IN messageProcessingModel -- typically, SNMP version 554 IN maxMessageSize -- from the received message 555 IN securityParameters -- from the received message 556 IN securityModel -- from the received message 557 IN securityLevel -- from the received message 558 IN wholeMsg -- as received on the wire 559 IN wholeMsgLength -- length as received on the wire 560 IN tmStateReference -- (NEW) from the Transport Model 561 OUT securityEngineID -- authoritative SNMP entity 562 OUT securityName -- identification of the principal 563 OUT scopedPDU, -- message (plaintext) payload 564 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 565 OUT securityStateReference -- reference to security state 566 ) -- information, needed for response 568 5.2. Elements of Procedure for Incoming Messages 570 1) Set the securityEngineID to the local snmpEngineID. 572 2) If tmStateReference does not refer to a cache containing values 573 for tmTransportDomain, tmTransportAddress, tmSecurityName and 574 tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is 575 incremented, an error indication is returned to the calling module, 576 and Security Model processing stops for this message. 578 3) Copy the tmSecurityName to securityName. 580 If the snmpTsmConfigurationUsePrefix object is set to true, then use 581 the tmTransportDomain to look up the corresponding prefix. 583 If the prefix lookup fails for any reason, then the 584 snmpTsmUnknownPrefixes counter is incremented, an error indication 585 is returned to the calling module, and message processing stops. 587 If the lookup succeeds, but the prefix length is less than one or 588 greater than four octets, then the snmpTsmInvalidPrefixes counter 589 is incremented, an error indication is returned to the calling 590 module, and message processing stops. 592 Set the securityName to be the concatenation of the prefix, a ':' 593 character (ASCII 0x3a) and the tmSecurityName. 595 4) Compare the value of tmTransportSecurityLevel in the 596 tmStateReference cache to the value of the securityLevel parameter 597 passed in the processIncomingMsg ASI. If securityLevel specifies 598 privacy (Priv), and tmTransportSecurityLevel specifies no privacy 599 (noPriv), or securityLevel specifies authentication (auth) and 600 tmTransportSecurityLevel specifies no authentication (noAuth) was 601 provided by the Transport Model, then the 602 snmpTsmInadequateSecurityLevels counter is incremented, an error 603 indication (unsupportedSecurityLevel) together with the OID and value 604 of the incremented counter is returned to the calling module, and 605 Transport Security Model processing stops for this message. 607 5) The tmStateReference is cached as cachedSecurityData, so that a 608 possible response to this message will use the same security 609 parameters. Then securityStateReference is set for subsequent 610 reference to this cached data. 612 6) The scopedPDU component is extracted from the wholeMsg. 614 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 615 size allowed for a scopedPDU for a possible Response message. 617 8) The statusInformation is set to success and a return is made to 618 the calling module passing back the OUT parameters as specified in 619 the processIncomingMsg ASI. 621 6. MIB Module Overview 623 This MIB module provides objects for use only by the Transport 624 Security Model. It defines a configuration scalar and related error 625 counters. 627 6.1. Structure of the MIB Module 629 Objects in this MIB module are arranged into subtrees. Each subtree 630 is organized as a set of related objects. The overall structure and 631 assignment of objects to their subtrees, and the intended purpose of 632 each subtree, is shown below. 634 6.1.1. The snmpTsmStats Subtree 636 This subtree contains error counters specific to the Transport 637 Security Model. 639 6.1.2. The snmpTsmConfiguration Subtree 641 This subtree contains a configuration object that enables 642 administrators to specify if they want a transport domain prefix 643 prepended to securityNames for use by applications. 645 6.2. Relationship to Other MIB Modules 647 Some management objects defined in other MIB modules are applicable 648 to an entity implementing the Transport Security Model. In 649 particular, it is assumed that an entity implementing the Transport 650 Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the 651 SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and 652 the SNMPv2-MIB [RFC3418]. These are not needed to implement the 653 SNMP-TSM-MIB. 655 6.2.1. MIB Modules Required for IMPORTS 657 The following MIB module imports items from [RFC2578], [RFC2579], and 658 [RFC2580]. 660 7. MIB module definition 662 SNMP-TSM-MIB DEFINITIONS ::= BEGIN 664 IMPORTS 665 MODULE-IDENTITY, OBJECT-TYPE, 666 mib-2, Counter32 667 FROM SNMPv2-SMI 668 MODULE-COMPLIANCE, OBJECT-GROUP 669 FROM SNMPv2-CONF 670 TruthValue 671 FROM SNMPv2-TC 672 ; 674 snmpTsmMIB MODULE-IDENTITY 675 LAST-UPDATED "200903090000Z" 676 ORGANIZATION "ISMS Working Group" 677 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 678 Subscribe: isms-request@lists.ietf.org 680 Chairs: 682 Juergen Quittek 683 NEC Europe Ltd. 684 Network Laboratories 685 Kurfuersten-Anlage 36 686 69115 Heidelberg 687 Germany 688 +49 6221 90511-15 689 quittek@netlab.nec.de 691 Juergen Schoenwaelder 692 Jacobs University Bremen 693 Campus Ring 1 694 28725 Bremen 695 Germany 696 +49 421 200-3587 697 j.schoenwaelder@iu-bremen.de 699 Editor: 700 David Harrington 701 Huawei Technologies USA 702 1700 Alma Dr. 703 Plano TX 75075 704 USA 705 +1 603-436-8634 706 ietfdbh@comcast.net 708 Wes Hardaker 709 Sparta, Inc. 710 P.O. Box 382 711 Davis, CA 95617 712 USA 713 +1 530 792 1913 714 ietf@hardakers.net 715 " 716 DESCRIPTION "The Transport Security Model MIB 718 In keeping with the RFC 3411 design decisions 719 to use self-contained documents, the RFC which 720 contains the definition of this MIB module also 721 includes the elements of procedure which are 722 needed for processing the Transport Security 723 Model for SNMP. These MIB objects 724 SHOULD NOT be modified via other subsystems 725 or models defined in other document.. 726 This allows the Transport Security Model 727 for SNMP to be designed and documented as 728 independent and self- contained, having no 729 direct impact on other modules, and this 730 allows this module to be upgraded and 731 supplemented as the need arises, and to 732 move along the standards track on different 733 time-lines from other modules. 735 Copyright (C) The IETF Trust (2009). This 736 version of this MIB module is part of RFC XXXX; 737 see the RFC itself for full legal notices. 738 -- NOTE to RFC editor: replace XXXX with actual RFC number 739 -- for this document and remove this note 740 " 742 REVISION "200903090000Z" 743 DESCRIPTION "The initial version, published in RFC XXXX. 744 -- NOTE to RFC editor: replace XXXX with actual RFC number 745 -- for this document and remove this note 746 " 748 ::= { mib-2 xxxx } 749 -- RFC Ed.: replace xxxx with IANA-assigned number and 750 -- remove this note 752 -- ---------------------------------------------------------- -- 753 -- subtrees in the SNMP-TSM-MIB 754 -- ---------------------------------------------------------- -- 756 snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 } 757 snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 } 758 snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 } 760 -- ------------------------------------------------------------- 761 -- Objects 762 -- ------------------------------------------------------------- 764 -- Statistics for the Transport Security Model 766 snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 } 768 snmpTsmInvalidCaches OBJECT-TYPE 769 SYNTAX Counter32 770 MAX-ACCESS read-only 771 STATUS current 772 DESCRIPTION "The number of incoming messages dropped because the 773 tmStateReference referred to an invalid cache. 774 " 775 ::= { snmpTsmStats 1 } 777 snmpTsmInadequateSecurityLevels OBJECT-TYPE 778 SYNTAX Counter32 779 MAX-ACCESS read-only 780 STATUS current 781 DESCRIPTION "The number of incoming messages dropped because 782 the securityLevel asserted by the transport model was 783 less than the securityLevel requested by the 784 application. 785 " 786 ::= { snmpTsmStats 2 } 788 snmpTsmUnknownPrefixes OBJECT-TYPE 789 SYNTAX Counter32 790 MAX-ACCESS read-only 791 STATUS current 792 DESCRIPTION "The number of messages dropped because 793 snmpTsmConfigurationUsePrefix was set to true and 794 there is no known prefix for the specified transport 795 domain. 796 " 797 ::= { snmpTsmStats 3 } 799 snmpTsmInvalidPrefixes OBJECT-TYPE 800 SYNTAX Counter32 801 MAX-ACCESS read-only 802 STATUS current 803 DESCRIPTION "The number of messages dropped because 804 the securityName associated with an outgoing message 805 did not contain a valid transport domain prefix. 806 " 807 ::= { snmpTsmStats 4 } 809 -- ------------------------------------------------------------- 810 -- Configuration 811 -- ------------------------------------------------------------- 813 -- Configuration for the Transport Security Model 815 snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 } 817 snmpTsmConfigurationUsePrefix OBJECT-TYPE 818 SYNTAX TruthValue 819 MAX-ACCESS read-write 820 STATUS current 821 DESCRIPTION "If this object is set to true then securityNames 822 passing to and from the application are expected to 823 contain a transport domain specific prefix. If this 824 object is set to true then a domain specific prefix 825 will be added by the TSM to the securityName for 826 incoming messages and removed from the securityName 827 when processing outgoing messages. Transport domains 828 and prefixes are maintained in a registry by IANA. 829 This object SHOULD persist across system reboots. 830 " 831 DEFVAL { false } 832 ::= { snmpTsmConfiguration 1 } 834 -- ------------------------------------------------------------- 835 -- snmpTsmMIB - Conformance Information 836 -- ------------------------------------------------------------- 838 snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 } 840 snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 } 842 -- ------------------------------------------------------------- 843 -- Compliance statements 844 -- ------------------------------------------------------------- 846 snmpTsmCompliance MODULE-COMPLIANCE 847 STATUS current 848 DESCRIPTION "The compliance statement for SNMP engines that support 849 the SNMP-TSM-MIB 850 " 851 MODULE 852 MANDATORY-GROUPS { snmpTsmGroup } 853 ::= { snmpTsmCompliances 1 } 855 -- ------------------------------------------------------------- 856 -- Units of conformance 857 -- ------------------------------------------------------------- 858 snmpTsmGroup OBJECT-GROUP 859 OBJECTS { 860 snmpTsmInvalidCaches, 861 snmpTsmInadequateSecurityLevels, 862 snmpTsmUnknownPrefixes, 863 snmpTsmInvalidPrefixes, 864 snmpTsmConfigurationUsePrefix 865 } 866 STATUS current 867 DESCRIPTION "A collection of objects for maintaining 868 information of an SNMP engine which implements 869 the SNMP Transport Security Model. 870 " 872 ::= { snmpTsmGroups 2 } 874 END 876 8. Security Considerations 878 This document describes a Security Model, compatible with the RFC3411 879 architecture, that permits SNMP to utilize security services provided 880 through an SNMP Transport Model. The Transport Security Model relies 881 on Transport Models for mutual authentication, binding of keys, 882 confidentiality and integrity. 884 The Transport Security Model relies on secure Transport Models to 885 provide an authenticated principal identifier and an assertion of 886 whether authentication and privacy are used during transport. This 887 Security Model SHOULD always be used with Transport Models that 888 provide adequate security, but "adequate security" is a configuration 889 and/or run-time decision of the operator or management application. 890 The security threats and how these threats are mitigated should be 891 covered in detail in the specifications of the Transport Models and 892 the underlying secure transports. 894 An authenticated principal identifier (securityName) is used in SNMP 895 applications, for purposes such as access control, notification 896 generation, and proxy forwarding. This security model supports 897 multiple transport models. Operators might judge some transports to 898 be more secure than others, so this security model can be configured 899 to prepend a prefix to the securityName to indicate the transport 900 model used to authenticate the principal. Operators can use the 901 prefixed securityName when making application decisions about levels 902 of access. 904 8.1. MIB module security 906 There are a number of management objects defined in this MIB module 907 with a MAX-ACCESS clause of read-write and/or read-create. Such 908 objects may be considered sensitive or vulnerable in some network 909 environments. The support for SET operations in a non-secure 910 environment without proper protection can have a negative effect on 911 network operations. These are the tables and objects and their 912 sensitivity/vulnerability: 914 o The snmpTsmConfigurationUsePrefix object could be modified, 915 creating a denial of service or authorizing SNMP messages that 916 would not have previously been authorized by an Access Control 917 Model (e.g. the VACM). 919 Some of the readable objects in this MIB module (i.e., objects with a 920 MAX-ACCESS other than not-accessible) may be considered sensitive or 921 vulnerable in some network environments. It is thus important to 922 control even GET and/or NOTIFY access to these objects and possibly 923 to even encrypt the values of these objects when sending them over 924 the network via SNMP. These are the tables and objects and their 925 sensitivity/vulnerability: 927 o All the counters in this module refer to configuration errors and 928 do not expose sensitive information. 930 SNMP versions prior to SNMPv3 did not include adequate security. 931 Even if the network itself is secure (for example by using IPsec), 932 even then, there is no control as to who on the secure network is 933 allowed to access and GET/SET (read/change/create/delete) the objects 934 in this MIB module. 936 It is RECOMMENDED that implementers consider the security features as 937 provided by the SNMPv3 framework (see [RFC3410] section 8), including 938 full support for the USM and Transport Security Model cryptographic 939 mechanisms (for authentication and privacy). 941 Further, deployment of SNMP versions prior to SNMPv3 is NOT 942 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 943 enable cryptographic security. It is then a customer/operator 944 responsibility to ensure that the SNMP entity giving access to an 945 instance of this MIB module is properly configured to give access to 946 the objects only to those principals (users) that have legitimate 947 rights to indeed GET or SET (change/create/delete) them. 949 9. IANA Considerations 951 IANA is requested to assign: 953 1. an SMI number under mib-2, for the MIB module in this document, 955 2. a value, preferably 4, to identify the Transport Security Model, 956 in the Security Models registry at 957 http://www.iana.org/assignments/snmp-number-spaces. This should 958 result in the following table of values: 960 Value Description References 961 ----- ----------- ---------- 962 0 reserved for 'any' [RFC3411] 963 1 reserved for SNMPv1 [RFC3411] 964 2 reserved for SNMPv2c [RFC3411] 965 3 User-Based Security Model (USM) [RFC3411] 966 YY Transport Security Model (TSM) [RFCXXXX] 968 -- NOTE to RFC editor: replace XXXX with actual RFC number 969 -- for this document and remove this note 970 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 971 throughout this document and remove this note. 973 10. Acknowledgements 975 The editors would like to thank Jeffrey Hutzelman for sharing his SSH 976 insights, and Dave Shield for an outstanding job wordsmithing the 977 existing document to improve organization and clarity. 979 Additionally, helpful document reviews were received from: Juergen 980 Schoenwaelder. 982 11. References 984 11.1. Normative References 986 [RFC2119] Bradner, S., "Key words for use in RFCs to 987 Indicate Requirement Levels", BCP 14, RFC 2119, 988 March 1997. 990 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 991 Schoenwaelder, Ed., "Structure of Management 992 Information Version 2 (SMIv2)", STD 58, 993 RFC 2578, April 1999. 995 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 996 Schoenwaelder, Ed., "Textual Conventions for 997 SMIv2", STD 58, RFC 2579, April 1999. 999 [RFC2580] McCloghrie, K., Perkins, D., and J. 1000 Schoenwaelder, "Conformance Statements for 1001 SMIv2", STD 58, RFC 2580, April 1999. 1003 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1004 Architecture for Describing Simple Network 1005 Management Protocol (SNMP) Management 1006 Frameworks", STD 62, RFC 3411, December 2002. 1008 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 1009 Wijnen, "Message Processing and Dispatching for 1010 the Simple Network Management Protocol (SNMP)", 1011 STD 62, RFC 3412, December 2002. 1013 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 1014 Network Management Protocol (SNMP) 1015 Applications", STD 62, RFC 3413, December 2002. 1017 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 1018 Subsystem for the Simple Network Management 1019 Protocol (SNMP)", draft-ietf-isms-tmsm-16 (work 1020 in progress), February 2009. 1022 11.2. Informative References 1024 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1025 Stewart, "Introduction and Applicability 1026 Statements for Internet-Standard Management 1027 Framework", RFC 3410, December 2002. 1029 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, 1030 "View-based Access Control Model (VACM) for the 1031 Simple Network Management Protocol (SNMP)", 1032 STD 62, RFC 3415, December 2002. 1034 [RFC3418] Presuhn, R., "Management Information Base (MIB) 1035 for the Simple Network Management Protocol 1036 (SNMP)", STD 62, RFC 3418, December 2002. 1038 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 1039 Wijnen, "Coexistence between Version 1, Version 1040 2, and Version 3 of the Internet-standard 1041 Network Management Framework", BCP 74, 1042 RFC 3584, August 2003. 1044 Appendix A. Notification Tables Configuration 1046 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 1047 configure notification originators with the destinations to which 1048 notifications should be sent. 1050 Most of the configuration is security-model-independent and 1051 transport-model-independent. 1053 The values we will use in the examples for the five model-independent 1054 security and transport parameters are: 1056 transportDomain = snmpSSHDomain 1058 transportAddress = 192.0.2.1:PPP 1060 securityModel = Transport Security Model 1062 securityName = alice 1064 securityLevel = authPriv 1066 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1067 port number for SNMP notifications over SSH, and remove this note. ] 1069 The following example will configure the Notification Originator to 1070 send informs to a Notification Receiver at 192.0.2.1:PPP using the 1071 securityName "alice". "alice" is the name for the recipient from the 1072 standpoint of the notification originator, and is used for processing 1073 access controls before sending a notification. 1075 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1076 port number for SNMP notifications over SSH, and remove this note. ] 1078 The columns marked with a "*" are the items that are Security Model 1079 or Transport Model specific. 1081 The configuration for the "alice" settings in the SNMP-VIEW-BASED- 1082 ACM-MIB objects are not shown here for brevity. First we configure 1083 which type of notification should be sent for this taglist (toCRTag). 1084 In this example, we choose to send an Inform. 1085 snmpNotifyTable row: 1086 snmpNotifyName CRNotif 1087 snmpNotifyTag toCRTag 1088 snmpNotifyType inform 1089 snmpNotifyStorageType nonVolatile 1090 snmpNotifyColumnStatus createAndGo 1092 Then we configure a transport address to which notifications 1093 associated with this taglist should be sent, and we specify which 1094 snmpTargetParamsEntry should be used (toCR) when sending to this 1095 transport address. 1097 snmpTargetAddrTable row: 1098 snmpTargetAddrName toCRAddr 1099 * snmpTargetAddrTDomain snmpSSHDomain 1100 * snmpTargetAddrTAddress 192.0.2.1:PPP 1101 snmpTargetAddrTimeout 1500 1102 snmpTargetAddrRetryCount 3 1103 snmpTargetAddrTagList toCRTag 1104 snmpTargetAddrParams toCR (must match below) 1105 snmpTargetAddrStorageType nonVolatile 1106 snmpTargetAddrColumnStatus createAndGo 1108 [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned 1109 port number for SNMP notifications over SSH, and remove this note. ] 1111 Then we configure which principal at the host should receive the 1112 notifications associated with this taglist. Here we choose "alice", 1113 who uses the Transport Security Model. 1114 snmpTargetParamsTable row: 1115 snmpTargetParamsName toCR 1116 snmpTargetParamsMPModel SNMPv3 1117 * snmpTargetParamsSecurityModel TransportSecurityModel 1118 snmpTargetParamsSecurityName "alice" 1119 snmpTargetParamsSecurityLevel authPriv 1120 snmpTargetParamsStorageType nonVolatile 1121 snmpTargetParamsRowStatus createAndGo 1123 A.1. Transport Security Model Processing for Notifications 1125 The Transport Security Model is called using the generateRequestMsg() 1126 ASI, with the following parameters (* are from the above tables): 1128 statusInformation = -- success or errorIndication 1129 generateRequestMsg( 1130 IN messageProcessingModel -- *snmpTargetParamsMPModel 1131 IN globalData -- message header, admin data 1132 IN maxMessageSize -- of the sending SNMP entity 1133 IN transportDomain -- *snmpTargetAddrTDomain 1134 IN transportAddress -- *snmpTargetAddrTAddress 1135 IN securityModel -- *snmpTargetParamsSecurityModel 1136 IN securityEngineID -- immaterial; TSM will ignore. 1137 IN securityName -- snmpTargetParamsSecurityName 1138 IN securityLevel -- *snmpTargetParamsSecurityLevel 1139 IN scopedPDU -- message (plaintext) payload 1140 OUT securityParameters -- filled in by Security Module 1141 OUT wholeMsg -- complete generated message 1142 OUT wholeMsgLength -- length of generated message 1143 OUT tmStateReference -- reference to transport info 1144 ) 1146 The Transport Security Model will determine the Transport Model based 1147 on the snmpTargetAddrTDomain. The selected Transport Model will 1148 select the appropriate transport connection using the 1149 tmStateReference cache created from the values of 1150 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1151 snmpTargetParamsSecurityLevel. 1153 Appendix B. Processing Differences between USM and Secure Transport 1155 USM and secure transports differ in the processing order and 1156 responsibilities within the RFC3411 architecture. While the steps 1157 are the same, they occur in a different order, and may be done by 1158 different subsystems. The following lists illustrate the difference 1159 in the flow and the responsibility for different processing steps for 1160 incoming messages when using USM and when using a secure transport. 1161 (These lists are simplified for illustrative purposes, and do not 1162 represent all details of processing. Transport Models must provide 1163 the detailed elements of procedure.) 1165 With USM, SNMPv1, and SNMPv2c Security Models, security processing 1166 starts when the Message Processing Model decodes portions of the 1167 ASN.1 message to extract header fields that are used to determine 1168 which Security Model should process the message to perform 1169 authentication, decryption, timeliness checking, integrity checking, 1170 and translation of parameters to model-independent parameters. By 1171 comparison, a secure transport performs those security functions on 1172 the message, before the ASN.1 is decoded. 1174 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 1175 are the same for USM and a secure transport. 1177 B.1. USM and the RFC3411 Architecture 1179 1) decode the ASN.1 header (Message Processing Model) 1181 2) determine the SNMP Security Model and parameters (Message 1182 Processing Model) 1184 3) verify securityLevel. [Security Model] 1186 4) translate parameters to model-independent parameters (Security 1187 Model) 1189 5) authenticate the principal, check message integrity and 1190 timeliness, and decrypt the message. [Security Model] 1192 6) determine the pduType in the decrypted portions (Message 1193 Processing Model), and 1195 7) pass on the decrypted portions with model-independent parameters. 1197 B.2. Transport Subsystem and the RFC3411 Architecture 1199 1) authenticate the principal, check integrity and timeliness of the 1200 message, and decrypt the message. [Transport Model] 1202 2) translate parameters to model-independent parameters (Transport 1203 Model) 1205 3) decode the ASN.1 header (Message Processing Model) 1207 4) determine the SNMP Security Model and parameters (Message 1208 Processing Model) 1210 5) verify securityLevel [Security Model] 1212 6) determine the pduType in the decrypted portions (Message 1213 Processing Model), and 1215 7) pass on the decrypted portions with model-independent security 1216 parameters 1218 If a message is secured using a secure transport layer, then the 1219 Transport Model should provide the translation from the authenticated 1220 identity (e.g., an SSH user name) to a human-friendly identifier 1221 (tmSecurityName) in step 2. The security model will provide a 1222 mapping from that identifier to a model-independent securityName. 1224 Appendix C. Open Issues 1226 Appendix D. Change Log 1228 From -11- to -12- 1230 Removed the SSH specific user@ syntax from the examples in 1231 appendix A 1233 From -10- to -11- 1235 Clairifed short vs long term information in tmState 1237 Removed duplicated text on Caches and References 1239 removed any references to LCD 1241 From -09- to -10- 1243 snmpTsmInvalidPrefix -> snmpTsmInvalidPrefixes 1245 Improvements to the prefix handling text in the EOP 1247 Removed transform selection 1249 Removed translation table 1251 Removed option to disable transports. 1253 Removed references to the LCD. 1255 Removed modifications to the "Cached Information" section to keep 1256 this consistent with other ISMS documents. 1258 Eliminated most "Relationship to Other MIB modules" text. 1260 Significant text cleanup 1262 From -08- to -09- 1264 Added the transport domain specific prefix adding/removing support 1265 as agreed to within the ISMS WG. The implementation is a bit 1266 different than what was originally discussed and is now housed 1267 entirely within this document and requires only a string 1268 allocation in the TM documents. In the end this form greatly 1269 reduced the documentation and procedure complexity in most 1270 documents. 1272 Added the snmpTsmConfigurationUsePrefix scalar. 1274 Removed the snmpTsmLCDTable since it is no longer needed. 1276 Removed the snmpTsmLCDDomainTable since it is not needed with the 1277 prefix addition replaced the functionality. 1279 From -07- to -08- 1281 Added tables to the MIB module to define a Transport Security 1282 Model-specific LCD, and updated the Elements of Procedure. This 1283 was because references to an abstract LCD sort of owned by both 1284 the security model and the transport model were found confusing. 1286 Realized we referred to the MIB module in text as SNMP-TRANSPORT- 1287 SM-MIB, but SNMP-TSM-MIB in the module. Changed all occurrences 1288 of SNMP-TRANSPORT-SM-MIB to SNMP-TSM-MIB, following RFC4181 1289 guidelines for naming. 1291 Updated Security Considerations to warn about writable objects, 1292 and added the new counter to the readable objects list. 1294 Changed snmpTsmLCDName to snmpTsmLCDTmSecurityName 1296 From -05- to -06- 1298 Fixed a bunch of editorial nits 1300 Fixed the note about terminology consistent with SNMPv3. 1302 Updated MIB assignment to by rfc4181 compatible 1304 Replaced tmSameSession with tmSameSecurity to eliminate session- 1305 matching from the security model. 1307 Eliminated all reference to the LCD from the Transport Security 1308 Model; the LCD is now TM-specific. 1310 Added tmTransportSecurityLevel and tmRequestedSecurityLevel to 1311 clarify incoming versus outgoing 1313 From -04- to -05- 1315 Removed check for empty securityParameters for incoming messages 1316 Added a note about terminology, for consistency with SNMPv3 rather 1317 than with RFC2828. 1319 From -03- to -04- 1321 Editorial changes requested by Tom Petch, to clarify behavior with 1322 SNMPv1/v2c 1324 Added early discussion of how TSM fits into the architecture to 1325 clarify behavior when RFC3584 security models are co-resident. 1327 Editorial changes requested by Bert Wijnen, to eliminate version- 1328 specific discussions. 1330 Removed sections on version-specific message formats. 1332 Removed discussion of SNMPv3 in Motivation section. 1334 Added discussion of request/response session matching. 1336 From -02- to -03- 1338 Editorial changes suggested by Juergen Schoenwaelder 1340 Capitalized Transport Models, Security Models, and Message 1341 Processing Models, to be consistent with RFC341x conventions. 1343 Eliminated some text that duplicated RFC3412, especially in 1344 Elements of Procedure. 1346 Changed the encoding of msgSecurityParameters 1348 Marked the (NEW) fields added to existing ASIs 1350 Modified text intro discussing relationships to other MIB modules. 1352 From -01- to -02- 1354 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1355 waiting for assignment 1357 cleaned up elements of procedure [todo]s 1359 use the same errorIndication as USM for unsupportedSecurityLevel 1361 fixed syntax of tsmInadequateSecurity counter 1362 changed the "can and will use" the same security parameters to 1363 "can use", to allow responses that have different security 1364 parameters than the request. 1366 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1368 cleaned up "MIB Modules Required for IMPORTS" 1370 From -00- to -01- 1372 made the Transport Model not know anything about the Security 1373 Model. 1375 modified the elements of procedure sections, given the 1376 implications of this change. 1378 simplified elements of procedure, removing most info specified in 1379 architecture/subsystem definitions. 1381 rethought the coexistence section 1383 noted the implications of the Transport Security Model on 1384 isAccessAllowed() 1386 modified all text related to the LCD. 1388 removed most of the MIB (now the TSM has no configuration 1389 parameters). 1391 added counters needed to support elements of procedure 1393 renamed MIB module, and registered under snmpModules 1395 updated IANA and Security Considerations 1397 updated references. 1399 modified the notification configurations. 1401 From SSHSM-04- to Transport-security-model-00 1403 added tsmUserTable 1405 updated Appendix - Notification Tables Configuration 1406 remove open/closed issue appendices 1408 changed tmSessionReference to tmStateReference 1410 Authors' Addresses 1412 David Harrington 1413 Huawei Technologies (USA) 1414 1700 Alma Dr. Suite 100 1415 Plano, TX 75075 1416 USA 1418 Phone: +1 603 436 8634 1419 EMail: dharrington@huawei.com 1421 Wes Hardaker 1422 Sparta, Inc. 1423 P.O. Box 382 1424 Davis, CA 95617 1425 US 1427 Phone: +1 530 792 1913 1428 EMail: ietf@hardakers.net