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