idnits 2.17.1 draft-ietf-isms-transport-security-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1279. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1154 has weird spacing: '...tyLevel auth...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects which are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD not be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self-contained, having no direct impact on other modules, and allowing this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 25, 2007) is 6295 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: 'RFC2571' is mentioned on line 1022, but not defined ** Obsolete undefined reference: RFC 2571 (Obsoleted by RFC 3411) == Missing Reference: 'RFCXXXX' is mentioned on line 1023, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Standards Track January 25, 2007 5 Expires: July 29, 2007 7 Transport Security Model for SNMP 8 draft-ietf-isms-transport-security-model-02 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo describes a Transport Security Model for the Simple Network 42 Management Protocol. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. The Internet-Standard Management Framework . . . . . . . . 3 48 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 52 2. How Transport Security Model Fits in the Architecture . . . . 5 53 2.1. Security Capabilities of this Model . . . . . . . . . . . 5 54 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 6 56 2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 7 59 2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 8 60 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 9 62 3.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 10 63 3.1.2. securityLevel and msgFlags . . . . . . . . . . . . . . 10 64 3.1.3. msgSecurityParameters . . . . . . . . . . . . . . . . 11 65 3.2. Cached Information and References . . . . . . . . . . . . 11 66 3.2.1. securityStateReference . . . . . . . . . . . . . . . . 12 67 3.2.2. tmStateReference . . . . . . . . . . . . . . . . . . . 12 68 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 13 69 4.1. Security Processing for an Outgoing Message . . . . . . . 13 70 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 14 71 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 15 72 5.1. Security Processing for an Incoming Message . . . . . . . 15 73 5.2. Elements of Procedure for Incoming Messages . . . . . . . 16 74 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 17 76 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 17 77 6.3. The transportStats Subtree . . . . . . . . . . . . . . . . 17 78 6.4. Relationship to Other MIB Modules . . . . . . . . . . . . 17 79 6.4.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 17 80 6.4.2. MIB Modules Required for IMPORTS . . . . . . . . . . . 18 81 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 18 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 21 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 88 Appendix A. Notification Tables Configuration . . . . . . . . . . 24 89 A.1. Transport Security Model Processing . . . . . . . . . . . 25 90 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 This memo describes a Transport Security Model for the Simple Network 95 Management Protocol, for use with secure transport models in the 96 Transport Subsystem [I-D.ietf-isms-tmsm]. 98 This memo also defines a portion of the Management Information Base 99 (MIB) for use with network management protocols in TCP/IP based 100 internets. In particular it defines objects for monitoring and 101 managing the Transport Security Model for SNMP. 103 It is important to understand the SNMP architecture and the 104 terminology of the architecture to understand where the Transport 105 Security Model described in this memo fits into the architecture and 106 interacts with other subsystems and models within the architecture. 108 1.1. The Internet-Standard Management Framework 110 For a detailed overview of the documents that describe the current 111 Internet-Standard Management Framework, please refer to section 7 of 112 RFC 3410 [RFC3410]. 114 Managed objects are accessed via a virtual information store, termed 115 the Management Information Base or MIB. MIB objects are generally 116 accessed through the Simple Network Management Protocol (SNMP). 117 Objects in the MIB are defined using the mechanisms defined in the 118 Structure of Management Information (SMI). This memo specifies a MIB 119 module that is compliant to the SMIv2, which is described in STD 58, 120 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 121 [RFC2580]. 123 1.2. Conventions 125 The terms "manager" and "agent" are not used in this document, 126 because in the RFC 3411 architecture, all SNMP entities have the 127 capability of acting as either manager or agent or both depending on 128 the SNMP applications included in the engine. Where distinction is 129 required, the application names of Command Generator, Command 130 Responder, Notification Originator, Notification Receiver, and Proxy 131 Forwarder are used. See "SNMP Applications" [RFC3413] for further 132 information. 134 While security protocols frequently refer to a user, the terminology 135 used in RFC3411 [RFC3411] and in this memo is "principal". A 136 principal is the "who" on whose behalf services are provided or 137 processing takes place. A principal can be, among other things, an 138 individual acting in a particular role; a set of individuals, with 139 each acting in a particular role; an application or a set of 140 applications, or a combination of these within an administrative 141 domain. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 1.3. Modularity 149 The reader is expected to have read and understood the description of 150 the SNMP architecture, as defined in [RFC3411],and the architecture 151 extension specified in "Transport Subsystem for the Simple Network 152 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 153 external "lower layer transport" protocols to provide message 154 security, tied into the SNMP architecture through the transport 155 subsystem. The Transport Security Model is designed to work with 156 such lower-layer secure transport models. 158 In keeping with the RFC 3411 design decisions to use self-contained 159 documents, this memo includes the elements of procedure plus 160 associated MIB objects which are needed for processing the Transport 161 Security Model for SNMP. These MIB objects SHOULD not be referenced 162 in other documents. This allows the Transport Security Model to be 163 designed and documented as independent and self-contained, having no 164 direct impact on other modules, and allowing this module to be 165 upgraded and supplemented as the need arises, and to move along the 166 standards track on different time-lines from other modules. 168 This modularity of specification is not meant to be interpreted as 169 imposing any specific requirements on implementation. 171 1.4. Motivation 173 Version 3 of the Simple Network Management Protocol (SNMPv3) added 174 security to the previous versions of the protocol. The User-based 175 Security Model (USM) [RFC3414] was designed to be independent of 176 other existing security infrastructures, to ensure it could function 177 when third party authentication services were not available, such as 178 in a broken network. As a result, USM typically utilizes a separate 179 user and key management infrastructure. Operators have reported that 180 deploying another user and key management infrastructure in order to 181 use SNMPv3 is a reason for not deploying SNMPv3 at this point in 182 time. 184 This memo describes a security model that will make use of transport 185 models that rely on lower layer secure transports and existing and 186 commonly deployed security infrastructures. This security model is 187 designed to meet the security and operational needs of network 188 administrators, maximize usability in operational environments to 189 achieve high deployment success and at the same time minimize 190 implementation and deployment costs to minimize the time until 191 deployment is possible. 193 1.5. Constraints 195 The design of this SNMP Security Model is also influenced by the 196 following constraints: 197 1. When the requirements of effective management in times of network 198 stress are inconsistent with those of security, the design of 199 this model gives preference to effective management. 200 2. In times of network stress, the security protocol and its 201 underlying security mechanisms SHOULD NOT depend upon the ready 202 availability of other network services (e.g., Network Time 203 Protocol (NTP) or AAA protocols). 204 3. When the network is not under stress, the security model and its 205 underlying security mechanisms MAY depend upon the ready 206 availability of other network services. 207 4. It may not be possible for the security model to determine when 208 the network is under stress. 209 5. A security model should require no changes to the SNMP 210 architecture. 211 6. A security model should require no changes to the underlying 212 security protocol. 214 2. How Transport Security Model Fits in the Architecture 216 The Transport Security Model is designed to fit into the RFC3411 217 architecture as a security model in the security subsystem, and to 218 utilize the services of a secure transport model. 220 The transport model of an SNMP engine will perform the translation 221 between transport-specific security parameters and the SNMP-specific, 222 model-independent parameters securityName and securityLevel. To 223 maintain the RFC3411 modularity, the transport model does not know 224 which securityModel will be used for an incoming message; the message 225 processing model will determine the securityModel to be used, in a 226 message processing model dependent manner. In an SNMPv3 message, the 227 Transport Security Model should be specified in the message header. 229 2.1. Security Capabilities of this Model 231 2.1.1. Threats 233 The Transport Security Model, when used with suitable secure 234 transport models, provides protection against the threats identified 235 by the RFC 3411 architecture [RFC3411]. 237 Which threats are addressed depends on the transport model. The 238 Transport Security Model does not address any threats itself, but 239 delegates that responsibility to a secure transport model. 241 The Transport Security Model is called a security model to be 242 compatible with the RFC3411 architecure. However, this security 243 model does not provide security mechanisms such as authenticatio and 244 encryption itself, so it SHOULD always be used with a transport model 245 that provides appropriate security. 247 2.1.2. Security Levels 249 The RFC 3411 architecture recognizes three levels of security: 250 - without authentication and without privacy (noAuthNoPriv) 251 - with authentication but without privacy (authNoPriv) 252 - with authentication and with privacy (authPriv) 254 The model-independent securityLevel parameter is used to request 255 specific levels of security for outgoing messages, and to assert that 256 specific levels of security were applied during the transport and 257 processing of incoming messages. 259 The transport layer algorithms used to provide security SHOULD NOT be 260 exposed to the Transport Security Model, as the Transport Security 261 Model has no mechanisms by which it can test whether an assertion 262 made by a transport model is accurate. 264 The Transport Security Model trusts that the underlying secure 265 transport connection has been properly configured to support security 266 characteristics at least as strong as requested in securityLevel. 268 2.2. No Sessions 270 The Transport Security Model will associate state regarding each 271 message and each known remote engine with a single combination of 272 transportType, transportAddress, securityName, securityModel, and 273 securityLevel. 275 Some transport models will utilize sessions to maintain long-lived 276 state; others will use stateless transport. For reasons of module 277 independence, the Transport Security Model will make no assumptions 278 about there being a session of any kind. Each message may be totally 279 independent of other messages. Any binding of multiples messages 280 into a session is specific to the transport model. There may be 281 circumstances where having an snmp-specific session provided by a 282 security model is useful; such functionality is left to future 283 security models. 285 2.3. Coexistence 287 There are two primary factors which determine whether security modles 288 can coexist. First, there must be a mechanism to select different 289 security models at run-time. Second, the processing of one security 290 should not impact the processing of another security model. 292 In the RFC3411 architecture, a message processing model determines 293 which security model should be called. As of this writing, there are 294 three message processing models and three other security models: 295 SNMPv1, SNMPv2c, and the User-based Security Model. 297 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 298 74) [RFC3584] always selects the SNMPv1(1) security model for an 299 SNMPv1 message, or the SNMPv2c(2) security model for an SNMPv2c 300 message. Since there is no field in the message format that permits 301 specifying a security model, RFC3584 message processing does not 302 permit the selection of security models other than SNMPv1 or SNMPv2. 303 Therefore, the Transport Security Model can coexist with SNMPv1 and 304 SNMPv2c community-based security models, but the Transport Security 305 Model cannot be used with SNMPv1 or SNMPv2c messages. 307 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 308 the securityModel from the msgSecurityModel field of an incoming 309 SNMPv3Message. When the extracted value of msgSecurityModel is 310 transportSecurityModel(YY), security processing is directed to the 311 Transport Security Model. So for an outgoing message secured using 312 the Transport Security Model, msgSecurityModel should be set to 313 transportSecurityModel(YY). 315 The Transport Security Model uses its own MIB module for processing 316 to maintain independence from other security models. This allows the 317 Transport Security Model to coexist with other security models, such 318 as the User-based Security Model. 320 Note that the Transport Security Model may work with multiple 321 transport models, but the isAccessAllowed() primitive only accepts a 322 value for the security model, not for transport models. As a result, 323 it is not possible to have different access control rules for 324 different transport models that use the Transport Security Model. 326 2.4. Security Parameter Passing 328 For outgoing messages, Transport Security Model takes input provided 329 by the SNMP application, converts that information into suitable 330 transport and security parameters in a cache referenced by 331 tmStateReference. The wholeMsg and the tmStateReference are passed 332 to the appropriate transport model through a series of APIs, as 333 described in "Transport Subsystem for the Simple Network Management 334 Protocol" [I-D.ietf-isms-tmsm]. 336 For incoming messages, the transport model accepts messages from the 337 lower layer transport, and records the transport-related information 338 and security-related information, including a securityName that 339 represents the authenticated identity, and a securityLevel that 340 represents the security features provided during transport, in a 341 cache referenced by tmStateReference. The wholeMsg and the 342 tmStateReference are passed to the appropriate security model through 343 a series of APIs, as described in "Transport Subsystem for the Simple 344 Network Management Protocol" [I-D.ietf-isms-tmsm]. 346 For an incoming SNMPv3 message, the messaging model extracts the 347 requested securityLevel from the msgFlags field, and passes this to 348 the security model. The Transport Security Model verifies that the 349 securityLevel passed in the cache is at least as strong as the 350 securityLevel passed in the ASI securityLevel parameter. 352 2.5. Notifications and Proxy 354 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 355 management targets, including transportType, transportAddress, 356 securityName, securityModel, and securityLevel parameters, for 357 applications such as notifications and proxy. For the Transport 358 Security Model, transport type and address are configured in the 359 snmpTargetAddrTable, and the securityModel, securityName, and 360 securityLevel parameters are configured in the snmpTargetParamsTable. 362 The default approach is for an administrator to statically 363 preconfigure this information to identify the targets authorized to 364 receive notifications or perform proxy. 366 3. Message Formats 368 The syntax of an SNMP message using this Security Model adheres to 369 the message format defined in the version-specific Message Processing 370 Model document (for example [RFC3412]). At the time of this writing, 371 there are three defined message formats - SNMPv1, SNMPv2c, and 372 SNMPv3. The Transport Security Model deos not work with SNMPv1 and 373 SNMPv2c for reasons described above, so this memo only deals with 374 SNMPv3 messages. 376 The processing is compatible with the RFC 3412 primitives, 377 generateRequestMsg() and processIncomingMsg(), that show the data 378 flow between the Message Processor and the security model. 380 3.1. SNMPv3 Message Fields 382 The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416]. 384 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 386 SNMPv3Message ::= SEQUENCE { 387 -- identify the layout of the SNMPv3Message 388 -- this element is in same position as in SNMPv1 389 -- and SNMPv2c, allowing recognition 390 -- the value 3 is used for snmpv3 391 msgVersion INTEGER ( 0 .. 2147483647 ), 392 -- administrative parameters 393 msgGlobalData HeaderData, 394 -- security model-specific parameters 395 -- format defined by Security Model 396 msgSecurityParameters OCTET STRING, 397 msgData ScopedPduData 398 } 400 HeaderData ::= SEQUENCE { 401 msgID INTEGER (0..2147483647), 402 msgMaxSize INTEGER (484..2147483647), 404 msgFlags OCTET STRING (SIZE(1)), 405 -- .... ...1 authFlag 406 -- .... ..1. privFlag 407 -- .... .1.. reportableFlag 408 -- Please observe: 409 -- .... ..00 is OK, means noAuthNoPriv 410 -- .... ..01 is OK, means authNoPriv 411 -- .... ..10 reserved, MUST NOT be used. 412 -- .... ..11 is OK, means authPriv 414 msgSecurityModel INTEGER (1..2147483647) 415 } 417 ScopedPduData ::= CHOICE { 418 plaintext ScopedPDU, 419 encryptedPDU OCTET STRING -- encrypted scopedPDU value 420 } 422 ScopedPDU ::= SEQUENCE { 423 contextEngineID OCTET STRING, 424 contextName OCTET STRING, 425 data ANY -- e.g., PDUs as defined in RFC3416 426 } 427 END 429 The following describes how the Transport Security Model treats 430 certain fields in the message: 432 3.1.1. msgGlobalData 434 The msgGlobalData values are set by the Message Processing model 435 (e.g., SNMPv3 Message Processing), and are not modified by the 436 Transport Security Model. 438 msgMaxSize is determined by the implementation. 440 For outgoing messages, msgSecurityModel is set by the Message 441 Processing model (e.g., SNMPv3) to the IANA-assigned value for the 442 Transport Security Model. See 443 http://www.iana.org/assignments/snmp-number-spaces. 445 For outgoing messages, the value of msgFlags is set by the Message 446 Processing model (e.g., SNMPv3 Message Processing), which is not 447 necessarily the actual securityLevel applied to the message by the 448 transport model. 450 For incoming messages, the value of msgFlags is determined by the 451 Message Processing model (e.g., SNMPv3 Message Processing), and the 452 value is passed in the securityLevel parameter in the ASI between the 453 messaging model and the security model. 455 3.1.2. securityLevel and msgFlags 457 For an outgoing message, securityLevel is the requested security for 458 the message, passed in the ASIs. If a Transport Model cannot provide 459 the requested securityLevel, the model MUST describe a standard 460 behavior that is followed for that situation. If the Transport Model 461 is able to provide stronger than requested security, that may be 462 acceptable. If the Transport Model cannot provide at least the 463 requested level of security, the Transport Model MUST discard the 464 request and SHOULD notify the message processing model that the 465 request failed. 467 The msgFlags field in the SNMPv3 message is closely related to 468 securityLevel. msgFlags is Messaging Model dependent, while 469 securityLevel is Messaging Model independent. To maintain the 470 separation between subsystems, the Transport Model SHOULD NOT modify 471 Message Model dependent fields. As a result, msgFlags in the SNMPv3 472 message MAY reflect the requested securityLevel, not the actual 473 securityLevel applied to the message by the Transport Model. 475 Part of the responsibility of a Security Model is to ensure that the 476 actual security provided by the underlying transport layer security 477 mechanisms is configured to meet or exceed the securityLevel 478 requested. When the Security Model processes the incoming message, 479 it should compare the securityLevel provided by the messaging model 480 to the securityLevel provided by the transport model in 481 tmStateReference. If they differ, the Security Model should 482 determine whether the securityLevel provided by the transport model 483 is acceptable (e.g. the transport securityLevel is greater than or 484 equal to the requested securityLevel. If not, it should discard the 485 message. Depending on the model, the Security Model may issue a 486 reportPDU with a model-specific counter. 488 3.1.3. msgSecurityParameters 490 Since message security is provided by a "lower layer", and the 491 securityName parameter is always determined by the transport model 492 from the lower layer authentication method, the SNMP message does not 493 need to carry message security parameters within the 494 msgSecurityParameters field. 496 The field msgSecurityParameters in SNMPv3 messages has a data type of 497 OCTET STRING. To prevent its being used in a manner that could be 498 damaging, such as for carrying a virus or worm, when used with 499 Transport Security Model its value MUST be the BER serialization of a 500 zero-length OCTET STRING. 502 TransportSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS 503 ::= BEGIN 505 TransportSecurityParameters ::= 506 OCTET STRING 507 END 509 3.2. Cached Information and References 511 The RFC3411 architecture uses caches to store dynamic model-specific 512 information, and uses references in the ASIs to indicate in a model- 513 independent manner which cached information must flow between 514 subsystems. 516 There are two levels of state that may need to be maintained: the 517 security state in a request-response pair, and potentially long-term 518 state relating to transport and security. 520 This state is maintained in caches and a Local Configuration 521 Datastore (LCD). To simplify the elements of procedure, the release 522 of state information is not always explicitly specified. As a 523 general rule, if state information is available when a message being 524 processed gets discarded, the state related to that message should 525 also be discarded, and if state information is available when a 526 relationship between engines is severed, such as the closing of a 527 transport session, the state information for that relationship might 528 also be discarded. 530 This document differentiates the tmStateReference from the 531 securityStateReference. This document does not specify an 532 implementation strategy, only an abstract discussion of the data that 533 must flow between subsystems. An implementation MAY use one cache 534 and one reference to serve both functions, but an implementer must be 535 aware of the cache-release issues to prevent the cache from being 536 released before a security or transport model has had an opportunity 537 to extract the information it needs. 539 3.2.1. securityStateReference 541 From RFC3411: "For each message received, the Security Model caches 542 the state information such that a Response message can be generated 543 using the same security information, even if the Local Configuration 544 Datastore is altered between the time of the incoming request and the 545 outgoing response. 547 A Message Processing Model has the responsibility for explicitly 548 releasing the cached data if such data is no longer needed. To 549 enable this, an abstract securityStateReference data element is 550 passed from the Security Model to the Message Processing Model. The 551 cached security data may be implicitly released via the generation of 552 a response, or explicitly released by using the stateRelease 553 primitive, as described in RFC3411 section 4.5.1." 555 The information saved should include the model-independent parameters 556 (transportType, transportAddress, securityName, securityModel, and 557 securityLevel), related security parameters, and other information 558 needed to match the response with the request. The Message 559 Processing Model has the responsibility for explicitly releasing the 560 securityStateReference when such data is no longer needed. The 561 securityStateReference cached data may be implicitly released via the 562 generation of a response, or explicitly released by using the 563 stateRelease primitive, as described in RFC 3411 section 4.5.1." 565 If the transport model connection is closed between the time a 566 Request is received and a Response message is being prepared, then 567 the Response message MAY be discarded. 569 3.2.2. tmStateReference 571 For each message or transport session, information about the message 572 security is stored in the cache to pass model- and mechanism-specific 573 parameters. The state referenced by tmStateReference may be saved 574 across multiple messages, in a Local Configuration Datastore (LCD), 575 as compared to securityStateReference which is only saved for the 576 life of a request-response pair of messages. 578 The format of the cache and the LCD are implementation-specific. 580 4. Processing an Outgoing Message 582 An error indication may return an OID and value for an incremented 583 counter and a value for securityLevel, and values for contextEngineID 584 and contextName for the counter, and the securityStateReference if 585 the information is available at the point where the error is 586 detected. 588 4.1. Security Processing for an Outgoing Message 590 This section describes the procedure followed by the Transport 591 Security Model. 593 The parameters needed for generating a message are supplied to the 594 security model by the message processing model via the 595 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 596 Subsystem architectural extension has added the transportDomain, 597 transportAddress, and tmStateReference parameters to the original 598 RFC3411 ASIs. 600 statusInformation = -- success or errorIndication 601 generateRequestMsg( 602 IN messageProcessingModel -- typically, SNMP version 603 IN globalData -- message header, admin data 604 IN maxMessageSize -- of the sending SNMP entity 605 IN transportDomain -- as specified by application 606 IN transportAddress -- as specified by application 607 IN securityModel -- for the outgoing message 608 IN securityEngineID -- authoritative SNMP entity 609 IN securityName -- on behalf of this principal 610 IN securityLevel -- Level of Security requested 611 IN scopedPDU -- message (plaintext) payload 612 OUT securityParameters -- filled in by Security Module 613 OUT wholeMsg -- complete generated message 614 OUT wholeMsgLength -- length of generated message 615 OUT tmStateReference -- reference to transport info 616 ) 618 statusInformation = -- success or errorIndication 619 generateResponseMsg( 620 IN messageProcessingModel -- typically, SNMP version 621 IN globalData -- message header, admin data 622 IN maxMessageSize -- of the sending SNMP entity 623 IN transportDomain -- as specified by application 624 IN transportAddress -- as specified by application 625 IN securityModel -- for the outgoing message 626 IN securityEngineID -- authoritative SNMP entity 627 IN securityName -- on behalf of this principal 628 IN securityLevel -- Level of Security requested 629 IN scopedPDU -- message (plaintext) payload 630 IN securityStateReference -- reference to security state 631 -- information from original 632 -- request 633 OUT securityParameters -- filled in by Security Module 634 OUT wholeMsg -- complete generated message 635 OUT wholeMsgLength -- length of generated message 636 OUT tmStateReference -- reference to transport info 637 ) 639 Note that the Transport Subystem architectural extension adds 640 transportDomain, transportAddress, and tmStateReference to these 641 ASIs. 643 4.2. Elements of Procedure for Outgoing Messages 645 1) verify that securityModel is transportSecurityModel(YY). If not, 646 then an error indication is returned to the calling message model, 647 and security model processing stops for this message. 649 2) If there is a securityStateReference, then this is a response to a 650 request, so extract the cached security data. This should include 651 transportDomain, transportAddress, securityName, securityLevel, and 652 securityModel, and a tmStateReference. The cachedSecurityData for 653 this message can now be discarded. 655 3) If there is no securityStateReference, then find or create an 656 entry in a Local Configuration Datastore containing the provided 657 transportDomain, transportAddress, securityName, securityLevel, and 658 securityModel, and create a tmStateReference to reference the entry. 660 4) fill in the msgSecurityModel with the value for 661 transportSecurityModel(YY). 663 5) fill in the msgFlags corresponding to the securityLevel specified 664 in the generateRequest() or generateResponse() parameter. 666 6) fill in the securityParameters with the serialization of a zero- 667 length OCTET STRING. 669 7) The plaintext scopedPDU serves as the msgData of the message. 671 8) Combine the message parts into a wholeMsg and calculate 672 wholeMsgLength. 674 9) The completed message (wholeMsg) with its length (wholeMsgLength) 675 and securityParameters (a zero-length octet string) and 676 tmStateReference is returned to the calling messaging model with the 677 statusInformation set to success. 679 5. Processing an Incoming SNMP Message 681 An error indication may return an OID and value for an incremented 682 counter and a value for securityLevel, and values for contextEngineID 683 and contextName for the counter, and the securityStateReference if 684 the information is available at the point where the error is 685 detected. 687 5.1. Security Processing for an Incoming Message 689 This section describes the procedure followed by the Transport 690 Security Model whenever it receives an incoming message from a 691 Message Processing Model. The abstract service primitive from a 692 Message Processing Model to the Security Subsystem for a received 693 message is: 695 statusInformation = -- errorIndication or success 696 -- error counter OID/value if error 697 processIncomingMsg( 698 IN messageProcessingModel -- typically, SNMP version 699 IN maxMessageSize -- of the sending SNMP entity 700 IN securityParameters -- for the received message 701 IN securityModel -- for the received message 702 IN securityLevel -- Level of Security 703 IN wholeMsg -- as received on the wire 704 IN wholeMsgLength -- length as received on the wire 705 IN tmStateReference -- from the transport model 706 OUT securityEngineID -- authoritative SNMP entity 707 OUT securityName -- identification of the principal 708 OUT scopedPDU, -- message (plaintext) payload 709 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 710 OUT securityStateReference -- reference to security state 711 ) -- information, needed for response 713 5.2. Elements of Procedure for Incoming Messages 715 1) verify that securityModel is transportSecurityModel(YY). If not, 716 then an error indication is returned to the calling message model, 717 and security model processing stops for this message. 719 2) If the messageProcessingModel is SNMPv3, then the securityEngineID 720 is set to the local snmpEngineID, to satisfy the SNMPv3 message 721 processing defined in RFC 3412 section 7.2 13a). 723 3) If the received securityParameters is not the serialization of an 724 OCTET STRING formatted according to the transportSecurityParameters, 725 or the contained OCTET STRING is not empty, then the 726 snmpInASNParseErrs counter [RFC3418] is incremented, and an error 727 indication (parseError) is returned to the calling module, and 728 security model processing stops for this message. 730 4) if tmStateReference does not refer to a cache containing values 731 for securityName and securityLevel, then the tsmInvalidCache counter 732 is incremented, an error indication is returned to the calling 733 module, and security model processing stops for this message. 735 5) Extract the value of securityName from the cache referenced by 736 tmStateReference. 738 6) The scopedPDU component is extracted from the wholeMsg. 740 7) The maxSizeResponseScopedPDU is calculated. This is the maximum 741 size allowed for a scopedPDU for a possible Response message. 743 8) Compare the value of securityLevel in the cache referenced by 744 tmStateReference to the value of the securityLevel parameter passed 745 in the processIncomingMessage service primitive. If the parameter 746 specifies privacy (Priv), and the cache specifies no privacy (noPriv) 747 was provided by the transport model, or the parameter specifies 748 authentication (auth) and the cache specifies no authentication 749 (noAuth) was provided by the transport model, then the 750 tsmInadequateSecurity counter is incremented, and an error indication 751 (unsupportedSecurityLevel) together with the OID and value of the 752 incremented counter is returned to the calling module. 754 9) The information in the tmStateReference may be saved, in an 755 implementation-dependent manner, in a Local Configuration Datastore 756 (LCD) for subsequent usage. 758 10)The security data is cached as cachedSecurityData, so that a 759 possible response to this message can use the same security 760 parameters. Then securityStateReference is set for subsequent 761 reference to this cached data. For Transport Security Model, the 762 securityStateReference should include a reference to the 763 tmStateReference cache. 765 11) The statusInformation is set to success and a return is made to 766 the calling module passing back the OUT parameters as specified in 767 the processIncomingMsg primitive. 769 6. Overview 771 This MIB module provides management of the Transport Security Model. 772 It defines some needed textual conventions, and some statistics. 774 6.1. Structure of the MIB Module 776 Objects in this MIB module are arranged into subtrees. Each subtree 777 is organized as a set of related objects. The overall structure and 778 assignment of objects to their subtrees, and the intended purpose of 779 each subtree, is shown below. 781 6.2. Textual Conventions 783 Generic and Common Textual Conventions used in this document can be 784 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 786 6.3. The transportStats Subtree 788 This subtree contains counters specific to the Transport Security 789 Model, that provide information for identifying fault conditions. 791 6.4. Relationship to Other MIB Modules 793 Some management objects defined in other MIB modules are applicable 794 to an entity implementing Transport Security Model. In particular, 795 it is assumed that an entity implementing Transport Security Model 796 will implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB 797 [RFC3411] and the SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm]. 799 6.4.1. Relationship to the SNMPv2-MIB 801 The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being 802 mandatory for all systems, and the objects apply to the entity as a 803 whole. The 'system' group provides identification of the management 804 entity and certain other system-wide data. The snmpInASNParseErrs 805 counter is incremented during the elements of procedure. The SNMP- 806 TRANSPORT-SM-MIB does not duplicate those objects. 808 6.4.2. MIB Modules Required for IMPORTS 810 The following MIB module imports items from [RFC2578] and [RFC2580].. 812 7. MIB module definition 814 SNMP-TRANSPORT-SM-MIB DEFINITIONS ::= BEGIN 816 IMPORTS 817 MODULE-IDENTITY, OBJECT-TYPE, 818 snmpModules, Counter32 819 FROM SNMPv2-SMI 820 MODULE-COMPLIANCE, OBJECT-GROUP 821 FROM SNMPv2-CONF 822 ; 824 tsmMIB MODULE-IDENTITY 825 LAST-UPDATED "200701250000Z" 826 ORGANIZATION "ISMS Working Group" 827 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 828 Subscribe: isms-request@lists.ietf.org 830 Chairs: 831 Juergen Quittek 832 NEC Europe Ltd. 833 Network Laboratories 834 Kurfuersten-Anlage 36 835 69115 Heidelberg 836 Germany 837 +49 6221 90511-15 838 quittek@netlab.nec.de 840 Juergen Schoenwaelder 841 International University Bremen 842 Campus Ring 1 843 28725 Bremen 844 Germany 845 +49 421 200-3587 846 j.schoenwaelder@iu-bremen.de 848 Editor: 849 David Harrington 850 Huawei Technologies USA 851 1700 Alma Dr. 852 Plano TX 75075 853 USA 854 +1 603-436-8634 855 ietfdbh@comcast.net 856 " 857 DESCRIPTION "The Transport Security Model MIB 859 Copyright (C) The IETF Trust (2007). This 860 version of this MIB module is part of RFC XXXX; 861 see the RFC itself for full legal notices. 862 -- NOTE to RFC editor: replace XXXX with actual RFC number 863 -- for this document and remove this note 864 " 866 REVISION "200701250000Z" 867 DESCRIPTION "The initial version, published in RFC XXXX. 868 -- NOTE to RFC editor: replace XXXX with actual RFC number 869 -- for this document and remove this note 870 " 872 ::= { snmpModules xxxx } 873 -- RFC Ed.: replace xxxx with IANA-assigned number and 874 -- remove this note 876 -- ---------------------------------------------------------- -- 877 -- subtrees in the SNMP-TRANSPORT-SM-MIB 878 -- ---------------------------------------------------------- -- 880 tsmNotifications OBJECT IDENTIFIER ::= { tsmMIB 0 } 881 tsmMIBObjects OBJECT IDENTIFIER ::= { tsmMIB 1 } 882 tsmConformance OBJECT IDENTIFIER ::= { tsmMIB 2 } 884 -- ------------------------------------------------------------- 885 -- Objects 886 -- ------------------------------------------------------------- 888 -- Statistics for the Transport Security Model 890 tsmStats OBJECT IDENTIFIER ::= { tsmMIBObjects 1 } 892 tsmInvalidCache OBJECT-TYPE 893 SYNTAX Counter32 894 MAX-ACCESS read-only 895 STATUS current 896 DESCRIPTION "The number of messages dropped because the 897 tmStateReference referred to an invalid cache. 898 " 899 ::= { tsmStats 1 } 901 tsmInadequateSecurity OBJECT-TYPE 902 SYNTAX Counter32 903 MAX-ACCESS read-only 904 STATUS current 905 DESCRIPTION "The number of incoming messages dropped because 906 the actual securtityLevel provided was less than 907 the requested securityLevel. 908 " 909 ::= { tsmStats 2 } 911 -- ------------------------------------------------------------- 912 -- tsmMIB - Conformance Information 913 -- ------------------------------------------------------------- 915 tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } 917 tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } 919 -- ------------------------------------------------------------- 920 -- Units of conformance 921 -- ------------------------------------------------------------- 922 tsmGroup OBJECT-GROUP 923 OBJECTS { 924 tsmInvalidCache, 925 tsmInadequateSecurity 926 } 927 STATUS current 928 DESCRIPTION "A collection of objects for maintaining 929 information of an SNMP engine which implements 930 the SNMP Transport Security Model. 931 " 933 ::= { tsmGroups 2 } 935 -- ------------------------------------------------------------- 936 -- Compliance statements 937 -- ------------------------------------------------------------- 939 tsmCompliance MODULE-COMPLIANCE 940 STATUS current 941 DESCRIPTION 942 "The compliance statement for SNMP engines that support 943 the SNMP-TRANSPORT-SM-MIB" 944 MODULE 945 MANDATORY-GROUPS { tsmGroup } 946 ::= { tsmCompliances 1 } 948 END 950 8. Security Considerations 952 This document describes a security model that permits SNMP to utilize 953 security services provided through an SNMP transport model. The 954 Transport Security Model relies on transport models for mutual 955 authentication, binding of keys, confidentiality and integrity. The 956 security threats and how those threats are mitigated should be 957 covered in detail in the specification of the transport model and the 958 underlying secure transport. 960 Transport Security Model relies on a transport model to provide an 961 authenticated principal for mapping to securityName, and an assertion 962 for mapping to securityLevel, for access control purposes. 964 The Transport Security Model is called a security model to be 965 compatible with the RFC3411 architecure. However, this security 966 model provides no security itself. It SHOULD always be used with a 967 transport model that provides security, but this is a run-time 968 decision of the operator or management application, or a 969 configuration decision of an operator. 971 8.1. MIB module security 973 There are no management objects defined in this MIB module that have 974 a MAX-ACCESS clause of read-write and/or read-create. So, if this 975 MIB module is implemented correctly, then there is no risk that an 976 intruder can alter or create any management objects of this MIB 977 module via direct SNMP SET operations. 979 Some of the readable objects in this MIB module (i.e., objects with a 980 MAX-ACCESS other than not-accessible) may be considered sensitive or 981 vulnerable in some network environments. It is thus important to 982 control even GET and/or NOTIFY access to these objects and possibly 983 to even encrypt the values of these objects when sending them over 984 the network via SNMP. These are the tables and objects and their 985 sensitivity/vulnerability: 986 o tmsInvalidCache and tmsInadeqauteSecuirty may make it easier for 987 an attacker to detect vulnerabilities. 989 SNMP versions prior to SNMPv3 did not include adequate security. 990 Even if the network itself is secure (for example by using IPSec or 991 SSH), even then, there is no control as to who on the secure network 992 is allowed to access and GET/SET (read/change/create/delete) the 993 objects in this MIB module. 995 It is RECOMMENDED that implementers consider the security features as 996 provided by the SNMPv3 framework (see [RFC3410] section 8), including 997 full support for the USM and Transport Security Model cryptographic 998 mechanisms (for authentication and privacy). 1000 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1001 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1002 enable cryptographic security. It is then a customer/operator 1003 responsibility to ensure that the SNMP entity giving access to an 1004 instance of this MIB module is properly configured to give access to 1005 the objects only to those principals (users) that have legitimate 1006 rights to indeed GET or SET (change/create/delete) them. 1008 9. IANA Considerations 1010 IANA is requested to assign: 1011 1. an SMI number under snmpModules, for the MIB module in this 1012 document, 1013 2. a value, preferably 4, to identify the Transport Security Model, 1014 in the Security Models registry at 1015 http://www.iana.org/assignments/snmp-number-spaces. This should 1016 result in the following table of values: 1017 Value Description References 1018 ----- ----------- ---------- 1019 0 reserved for 'any' [RFC2571, RFC3411] 1020 1 reserved for SNMPv1 [RFC2571, RFC3411] 1021 2 reserved for SNMPv2c [RFC2571, RFC3411] 1022 3 User-Based Security Model (USM) [RFC2571, RFC3411] 1023 YY Transport Security Model (TSM) [RFCXXXX] 1025 -- NOTE to RFC editor: replace XXXX with actual RFC number 1026 -- for this document and remove this note 1027 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 1028 throughout this document and remove this note. 1030 10. References 1032 10.1. Normative References 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to 1035 Indicate Requirement Levels", BCP 14, RFC 2119, 1036 March 1997. 1038 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1039 Schoenwaelder, Ed., "Structure of Management 1040 Information Version 2 (SMIv2)", STD 58, 1041 RFC 2578, April 1999. 1043 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1044 Schoenwaelder, Ed., "Textual Conventions for 1045 SMIv2", STD 58, RFC 2579, April 1999. 1047 [RFC2580] McCloghrie, K., Perkins, D., and J. 1048 Schoenwaelder, "Conformance Statements for 1049 SMIv2", STD 58, RFC 2580, April 1999. 1051 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1052 Architecture for Describing Simple Network 1053 Management Protocol (SNMP) Management 1054 Frameworks", STD 62, RFC 3411, December 2002. 1056 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 1057 Wijnen, "Message Processing and Dispatching for 1058 the Simple Network Management Protocol (SNMP)", 1059 STD 62, RFC 3412, December 2002. 1061 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 1062 Network Management Protocol (SNMP) 1063 Applications", STD 62, RFC 3413, December 2002. 1065 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 1066 Security Model (USM) for version 3 of the 1067 Simple Network Management Protocol (SNMPv3)", 1068 STD 62, RFC 3414, December 2002. 1070 [RFC3416] Presuhn, R., "Version 2 of the Protocol 1071 Operations for the Simple Network Management 1072 Protocol (SNMP)", STD 62, RFC 3416, 1073 December 2002. 1075 [RFC3418] Presuhn, R., "Management Information Base (MIB) 1076 for the Simple Network Management Protocol 1077 (SNMP)", STD 62, RFC 3418, December 2002. 1079 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 1080 Wijnen, "Coexistence between Version 1, Version 1081 2, and Version 3 of the Internet-standard 1082 Network Management Framework", BCP 74, 1083 RFC 3584, August 2003. 1085 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 1086 Subsystem for the Simple Network Management 1087 Protocol (SNMP)", draft-ietf-isms-tmsm-05 (work 1088 in progress), December 2006. 1090 10.2. Informative References 1092 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1093 Stewart, "Introduction and Applicability 1094 Statements for Internet-Standard Management 1095 Framework", RFC 3410, December 2002. 1097 Appendix A. Notification Tables Configuration 1099 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 1100 configure notification originators with the destinations to which 1101 notifications should be sent. 1103 Most of the configuration is security-model-independent and 1104 transport-model-independent. 1106 The values we will use in the examples for the five model-independent 1107 security and transport parameters are: 1108 transportType = snmpSSHDomain 1109 transportAddress = 192.0.2.1:162 1110 securityModel = Transport Security Model 1111 securityName = sampleUser 1112 securityLevel = authPriv 1114 The following example will configure the Notification Originator to 1115 send informs to a Notification Receiver at host 192.0.2.1 port 162 1116 using the securityName "sampleUser". The columns marked with a "*" 1117 are the items that are Security Model or Transport Model specific. 1119 The configuration for the "sampleUser" settings in the SNMP-VIEW- 1120 BASED-ACM-MIB objects are not shown here for brevity. First we 1121 configure which type of notification should be sent for this taglist 1122 (toCRTag). In this example, we choose to send an Inform. 1123 snmpNotifyTable row: 1124 snmpNotifyName CRNotif 1125 snmpNotifyTag toCRTag 1126 snmpNotifyType inform 1127 snmpNotifyStorageType nonVolatile 1128 snmpNotifyColumnStatus createAndGo 1130 Then we configure a transport address to which notifications 1131 associated with this taglist should be sent, and we specify which 1132 snmpTargetParamsEntry should be used (toCR) when sending to this 1133 transport address. 1135 snmpTargetAddrTable row: 1136 snmpTargetAddrName toCRAddr 1137 * snmpTargetAddrTDomain snmpSSHDomain 1138 snmpTargetAddrTAddress 192.0.2.1:162 1139 snmpTargetAddrTimeout 1500 1140 snmpTargetAddrRetryCount 3 1141 snmpTargetAddrTagList toCRTag 1142 snmpTargetAddrParams toCR (must match below) 1143 snmpTargetAddrStorageType nonVolatile 1144 snmpTargetAddrColumnStatus createAndGo 1146 Then we configure which prinicipal at the host should receive the 1147 notifications associated with this taglist. Here we choose 1148 "sampleUser", who uses the Transport Security Model. 1149 snmpTargetParamsTable row: 1150 snmpTargetParamsName toCR 1151 snmpTargetParamsMPModel SNMPv3 1152 * snmpTargetParamsSecurityModel TransportSecurityModel 1153 * snmpTargetParamsSecurityName "sampleUser" 1154 snmpTargetParamsSecurityLevel authPriv 1155 snmpTargetParamsStorageType nonVolatile 1156 snmpTargetParamsRowStatus createAndGo 1158 A.1. Transport Security Model Processing 1160 The Transport Security Model is called using the 1161 generateRequestMessage() ASI, with the following parameters (* are 1162 from the above tables): 1164 statusInformation = -- success or errorIndication 1165 generateRequestMsg( 1166 IN messageProcessingModel -- *snmpTargetParamsMPModel 1167 IN globalData -- message header, admin data 1168 IN maxMessageSize -- of the sending SNMP entity 1169 IN transportDomain -- *snmpTargetAddrTDomain 1170 IN transportAddress -- *snmpTargetAddrTAddress 1171 IN securityModel -- *snmpTargetParamsSecurityModel 1172 IN securityEngineID -- immaterial; TSM will ignore. 1173 IN securityName -- *snmpTargetParamsSecurityName 1174 IN securityLevel -- *snmpTargetParamsSecurityLevel 1175 IN scopedPDU -- message (plaintext) payload 1176 OUT securityParameters -- filled in by Security Module 1177 OUT wholeMsg -- complete generated message 1178 OUT wholeMsgLength -- length of generated message 1179 OUT tmStateReference -- reference to transport info 1180 ) 1182 The Transport Security Model will determine the transport model based 1183 on the snmpTargetAddrTDomain. The selected transport model will 1184 select the appropriate transport "session" using the 1185 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1186 snmpTargetParamsSecurityLevel. 1188 Appendix B. Change Log 1190 From -01- to -02- 1192 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1193 waiting for assignment 1194 cleaned up elements of procedure [todo]s 1195 use the same errorIndication as USM for UnsupportedSecurityLevel 1196 fixed syntax of tsmInadequateSecurity counter 1197 changed the "can and will use" the same security parameters to 1198 "can use", to allow responses that have different security 1199 parameters than the request. 1200 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1201 cleaned up "MIB Modules Required for IMPORTS" 1203 From -00- to -01- 1205 made the transport model not know anything about the security 1206 model. 1207 modified the elements of prcedure sections, given the implications 1208 of this change. 1209 simplified elelemnts of procedure, removing most info specified in 1210 architecture/subsystem definitons. 1211 rethought the coexistence section 1212 noted the implications of the Transport Security Model on 1213 isAccessAllowed() 1214 modified all text related to the LCD. 1215 removed most of the MIB (now the TSM has no configuration 1216 parameters). 1217 added counters needed to support elements of procedure 1218 renamed MIB module, and registered under snmpModules 1219 updated IANA and Security Considerations 1220 updated references. 1221 modified the notification configurations. 1223 From SSHSM-04- to Transport-security-model-00 1225 added tsmUserTable 1226 updated Appendix - Notification Tables Configuration 1227 remove open/closed issue appendices 1228 changed tmSessionReference to tmStateReference 1230 Author's Address 1232 David Harrington 1233 Huawei Technologies (USA) 1234 1700 Alma Dr. Suite 100 1235 Plano, TX 75075 1236 USA 1238 Phone: +1 603 436 8634 1239 EMail: dharrington@huawei.com 1241 Full Copyright Statement 1243 Copyright (C) The IETF Trust (2007). 1245 This document is subject to the rights, licenses and restrictions 1246 contained in BCP 78, and except as set forth therein, the authors 1247 retain all their rights. 1249 This document and the information contained herein are provided on an 1250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1252 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1253 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1254 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1257 Intellectual Property 1259 The IETF takes no position regarding the validity or scope of any 1260 Intellectual Property Rights or other rights that might be claimed to 1261 pertain to the implementation or use of the technology described in 1262 this document or the extent to which any license under such rights 1263 might or might not be available; nor does it represent that it has 1264 made any independent effort to identify any such rights. Information 1265 on the procedures with respect to rights in RFC documents can be 1266 found in BCP 78 and BCP 79. 1268 Copies of IPR disclosures made to the IETF Secretariat and any 1269 assurances of licenses to be made available, or the result of an 1270 attempt made to obtain a general license or permission for the use of 1271 such proprietary rights by implementers or users of this 1272 specification can be obtained from the IETF on-line IPR repository at 1273 http://www.ietf.org/ipr. 1275 The IETF invites any interested party to bring to its attention any 1276 copyrights, patents or patent applications, or other proprietary 1277 rights that may cover technology that may be required to implement 1278 this standard. Please address the information to the IETF at 1279 ietf-ipr@ietf.org. 1281 Acknowledgement 1283 Funding for the RFC Editor function is provided by the IETF 1284 Administrative Support Activity (IASA).