idnits 2.17.1 draft-ietf-isms-transport-security-model-04.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 1147. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1171. 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 994 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 (May 1, 2007) is 6204 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 862, but not defined ** Obsolete undefined reference: RFC 2571 (Obsoleted by RFC 3411) == Missing Reference: 'RFCXXXX' is mentioned on line 863, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-07 -- 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 May 1, 2007 5 Expires: November 2, 2007 7 Transport Security Model for SNMP 8 draft-ietf-isms-transport-security-model-04 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 November 2, 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 This memo also defines a portion of the Management Information Base 45 (MIB) for use with network management protocols in TCP/IP based 46 internets. In particular it defines objects for monitoring and 47 managing the Transport Security Model for SNMP. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. The Internet-Standard Management Framework . . . . . . . . 3 53 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. How the Transport Security Model Fits in the Architecture . . 5 58 2.1. Security Capabilities of this Model . . . . . . . . . . . 6 59 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 6 61 2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 8 64 2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 8 65 3. Cached Information and References . . . . . . . . . . . . . . 9 66 3.1. securityStateReference . . . . . . . . . . . . . . . . . . 9 67 3.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 9 68 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 69 4.1. Security Processing for an Outgoing Message . . . . . . . 10 70 4.2. securityLevel . . . . . . . . . . . . . . . . . . . . . . 11 71 4.3. Elements of Procedure for Outgoing Messages . . . . . . . 11 72 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 12 73 5.1. Security Processing for an Incoming Message . . . . . . . 12 74 5.2. Elements of Procedure for Incoming Messages . . . . . . . 12 75 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 13 77 6.2. The tsmStats Subtree . . . . . . . . . . . . . . . . . . . 14 78 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 14 79 6.3.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 14 80 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 14 81 6.3.3. MIB Modules Required for IMPORTS . . . . . . . . . . . 14 82 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 14 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 18 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 89 Appendix A. Notification Tables Configuration . . . . . . . . . . 20 90 A.1. Transport Security Model Processing . . . . . . . . . . . 22 91 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 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. 108 It is expected that reader will have also read and understood RFC3411 109 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 110 [RFC3418]. 112 1.1. The Internet-Standard Management Framework 114 For a detailed overview of the documents that describe the current 115 Internet-Standard Management Framework, please refer to section 7 of 116 RFC 3410 [RFC3410]. 118 Managed objects are accessed via a virtual information store, termed 119 the Management Information Base or MIB. MIB objects are generally 120 accessed through the Simple Network Management Protocol (SNMP). 121 Objects in the MIB are defined using the mechanisms defined in the 122 Structure of Management Information (SMI). This memo specifies a MIB 123 module that is compliant to the SMIv2, which is described in STD 58, 124 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 125 [RFC2580]. 127 1.2. Conventions 129 The terms "manager" and "agent" are not used in this document, 130 because in the RFC 3411 architecture, all SNMP entities have the 131 capability of acting as either manager or agent or both depending on 132 the SNMP applications included in the engine. Where distinction is 133 required, the application names of Command Generator, Command 134 Responder, Notification Originator, Notification Receiver, and Proxy 135 Forwarder are used. See "SNMP Applications" [RFC3413] for further 136 information. 138 While security protocols frequently refer to a user, the terminology 139 used in RFC3411 [RFC3411] and in this memo is "principal". A 140 principal is the "who" on whose behalf services are provided or 141 processing takes place. A principal can be, among other things, an 142 individual acting in a particular role; a set of individuals, with 143 each acting in a particular role; an application or a set of 144 applications, or a combination of these within an administrative 145 domain. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 1.3. Modularity 153 The reader is expected to have read and understood the description of 154 the SNMP architecture, as defined in [RFC3411], and the architecture 155 extension specified in "Transport Subsystem for the Simple Network 156 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 157 external "lower layer transport" protocols to provide message 158 security, tied into the SNMP architecture through the Transport 159 Subsystem. The Transport Security Model is designed to work with 160 such lower-layer secure Transport Models. 162 In keeping with the RFC 3411 design decisions to use self-contained 163 documents, this memo includes the elements of procedure plus 164 associated MIB objects which are needed for processing the Transport 165 Security Model for SNMP. These MIB objects SHOULD not be referenced 166 in other documents. This allows the Transport Security Model to be 167 designed and documented as independent and self-contained, having no 168 direct impact on other modules, and allowing this module to be 169 upgraded and supplemented as the need arises, and to move along the 170 standards track on different time-lines from other modules. 172 This modularity of specification is not meant to be interpreted as 173 imposing any specific requirements on implementation. 175 1.4. Motivation 177 This memo describes a Security Model to make use of Transport Models 178 that use lower layer secure transports and existing and commonly 179 deployed security infrastructures. This Security Model is designed 180 to meet the security and operational needs of network administrators, 181 maximize usability in operational environments to achieve high 182 deployment success and at the same time minimize implementation and 183 deployment costs to minimize the time until deployment is possible. 185 1.5. Constraints 187 The design of this SNMP Security Model is also influenced by the 188 following constraints: 190 1. In times of network stress, the security protocol and its 191 underlying security mechanisms SHOULD NOT depend solely upon the 192 ready availability of other network services (e.g., Network Time 193 Protocol (NTP) or Authentication, Authorization, and Accounting 194 (AAA) protocols). 196 2. When the network is not under stress, the Security Model and its 197 underlying security mechanisms MAY depend upon the ready 198 availability of other network services. 200 3. It may not be possible for the Security Model to determine when 201 the network is under stress. 203 4. A Security Model should require no changes to the SNMP 204 architecture. 206 5. A Security Model should require no changes to the underlying 207 security protocol. 209 2. How the Transport Security Model Fits in the Architecture 211 The Transport Security Model is designed to fit into the RFC3411 212 architecture as a Security Model in the Security Subsystem, and to 213 utilize the services of a secure Transport Model. 215 A cache, referenced by tmStateReference, is used to pass information 216 between the Transport Security Model and a Transport Model, and vice 217 versa. If the Transport Security Model is used with an insecure 218 Transport Model, then the cache is unlikely to be populated with 219 security parameters, which will cause the Transport Security Model to 220 return an error (see section 5.2) If another Security Model (eg 221 Community-based Security Model) is used with a secure Transport 222 Model, then the cache may be populated but the other Security Model 223 may be unaware of the cache and ignore its contents (eg deriving the 224 securityName from the Community name in the message instead of 225 deriving it from the cache). When the Transport Security Model is 226 used with a secure Transport Model, the information in the cache is 227 used by the Transport Security Model to translate between the 228 security model-independent securityName and any identity used by the 229 secure transport; and to record the tmSecurityLevel provided for the 230 message by the transport (a level of security which may exceed the 231 securityLevel requested for the message by the application). 233 The Transport Model of an SNMP engine will perform the translation 234 between transport-specific security parameters and the SNMP-specific, 235 model-independent parameters securityName and securityLevel. To 236 maintain the RFC3411 modularity, the Transport Model does not know 237 which securityModel will be used for an incoming message; the Message 238 Processing Model will determine the securityModel to be used, in a 239 Message Processing Model dependent manner. 241 2.1. Security Capabilities of this Model 243 2.1.1. Threats 245 The Transport Security Model, when used with suitable secure 246 Transport Models, provides protection against the threats identified 247 by the RFC 3411 architecture [RFC3411]. 249 Which threats are addressed depends on the Transport Model. The 250 Transport Security Model does not address any threats itself, but 251 delegates that responsibility to a secure Transport Model. 253 The Transport Security Model is called a Security Model to be 254 compatible with the RFC3411 architecture. However, this Security 255 Model does not provide security mechanisms such as authentication and 256 encryption itself, so it SHOULD always be used with a Transport Model 257 that provides appropriate security. 259 2.1.2. Security Levels 261 The RFC 3411 architecture recognizes three levels of security: 263 - without authentication and without privacy (noAuthNoPriv) 265 - with authentication but without privacy (authNoPriv) 267 - with authentication and with privacy (authPriv) 269 The model-independent securityLevel parameter is used to request 270 specific levels of security for outgoing messages, and to assert that 271 specific levels of security were applied during the transport and 272 processing of incoming messages. 274 The transport layer algorithms used to provide security SHOULD NOT be 275 exposed to the Transport Security Model, as the Transport Security 276 Model has no mechanisms by which it can test whether an assertion 277 made by a Transport Model is accurate. 279 The Transport Security Model trusts that the underlying secure 280 transport connection has been properly configured to support security 281 characteristics at least as strong as requested in securityLevel. 283 2.2. No Sessions 285 The Transport Security Model will associate state regarding each 286 message and each known remote engine with a single combination of 287 transportDomain, transportAddress, securityName, securityModel, and 288 securityLevel. 290 Some Transport Models will utilize sessions to maintain long-lived 291 state; others will use stateless transport. For reasons of module 292 independence, the Transport Security Model will make no assumptions 293 about there being a session of any kind. Each message may be totally 294 independent of other messages. Any binding of multiples messages 295 into a session is specific to the Transport Model. There may be 296 circumstances where having an SNMP-specific session provided by a 297 Security Model is useful; such functionality is left to future 298 Security Models. 300 2.3. Coexistence 302 There are two primary factors which determine whether Security Models 303 can coexist. First, there must be a mechanism to select different 304 Security Models at run-time. Second, the processing of one Security 305 Model should not impact the processing of another Security Model. 307 In the RFC3411 architecture, a Message Processing Model determines 308 which Security Model should be called. As of this writing, IANA has 309 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 310 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 311 SNMPv2c, and the User-based Security Model). 313 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 314 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 315 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 316 message. Since there is no field in the message format that permits 317 specifying a Security Model, RFC3584 message processing does not 318 permit the selection of Security Models other than SNMPv1 or SNMPv2. 319 Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or 320 SNMPv2 Message Processing Models **as defined in RFC3584** cannot use 321 the Transport Security Model. (This does not mean an SNMPv1 or 322 SNMPv2 message cannot use a secure transport model, only that the 323 RFC3584 MPM will not invoke this security model.) 325 The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact 326 for which there is no existing IETF specification. 328 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 329 the securityModel from the msgSecurityModel field of an incoming 330 SNMPv3Message. When the extracted value of msgSecurityModel is 331 transportSecurityModel(YY), security processing is directed to the 332 Transport Security Model. For an outgoing message to be secured 333 using the Transport Security Model, msgSecurityModel should be set to 334 transportSecurityModel(YY). 336 The Transport Security Model uses its own MIB module for processing 337 to maintain independence from other Security Models. This allows the 338 Transport Security Model to coexist with other Security Models, such 339 as the User-based Security Model. 341 Note that the Transport Security Model may work with multiple 342 Transport Models, but the isAccessAllowed() primitive only accepts a 343 value for the Security Model, not for Transport Models. As a result, 344 it is not possible to have different access control rules for 345 different Transport Models that use the Transport Security Model. 347 2.4. Security Parameter Passing 349 For outgoing messages, Transport Security Model takes input provided 350 by the SNMP application, converts that information into suitable 351 transport and security parameters in a cache referenced by 352 tmStateReference. The wholeMsg and the tmStateReference are passed 353 to the appropriate Transport Model through a series of APIs, as 354 described in "Transport Subsystem for the Simple Network Management 355 Protocol" [I-D.ietf-isms-tmsm]. 357 For incoming messages, the Transport Model accepts messages from the 358 lower layer transport, and records the transport-related information 359 and security-related information, including a securityName that 360 represents the authenticated identity, and a securityLevel that 361 represents the security features provided during transport, in a 362 cache referenced by tmStateReference. The wholeMsg and the 363 tmStateReference are passed to the appropriate Security Model through 364 a series of APIs, as described in "Transport Subsystem for the Simple 365 Network Management Protocol" [I-D.ietf-isms-tmsm]. 367 2.5. Notifications and Proxy 369 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 370 management targets, including transportDomain, transportAddress, 371 securityName, securityModel, and securityLevel parameters, for 372 applications such as notifications and proxy. For the Transport 373 Security Model, transport type and address are configured in the 374 snmpTargetAddrTable, and the securityModel, securityName, and 375 securityLevel parameters are configured in the snmpTargetParamsTable. 377 The default approach is for an administrator to statically configure 378 this information to identify the targets authorized to receive 379 notifications or perform proxy. 381 3. Cached Information and References 383 The RFC3411 architecture uses caches to store dynamic model-specific 384 information, and uses references in the ASIs to indicate in a model- 385 independent manner which cached information must flow between 386 subsystems. 388 There are two levels of state that may need to be maintained: the 389 security state in a request-response pair, and potentially long-term 390 state relating to transport and security. This document describes 391 caches, and differentiates the tmStateReference from the 392 securityStateReference, but how this is represented internally is an 393 implementation decision. 395 As a general rule, if state information is available when a message 396 being processed gets discarded, the state related to that message 397 should also be discarded, and if state information is available when 398 a relationship between engines is severed, such as the closing of a 399 transport session, the state information for that relationship might 400 also be discarded. 402 3.1. securityStateReference 404 The securityStateReference parameter is defined in RFC3411. A sample 405 model-specific cache can be found in RFC3414 [RFC3414]. 407 3.2. tmStateReference 409 For each transport session, information about the message security is 410 stored in a cache to pass model- and mechanism-specific parameters. 411 The state referenced by tmStateReference may be saved across multiple 412 messages, in a Local Configuration Datastore (LCD), as compared to 413 securityStateReference which is usually only saved for the life of a 414 request-response pair of messages. 416 For security reasons, if a secure transport session is closed between 417 the time a request message is received and the corresponding response 418 message is sent, then the response message MUST be discarded, even if 419 a new session has been established. Each Security Model SHOULD pass 420 a tmSameSession parameter in the tmStateReference cache for outgoing 421 messages to indicate whether the same session must be used for the 422 outgoing message as was used for the corresponding incoming message. 424 The format of the cache and the LCD are implementation-specific. 426 4. Processing an Outgoing Message 428 An error indication may return an OID and value for an incremented 429 counter and a value for securityLevel, and values for contextEngineID 430 and contextName for the counter, and the securityStateReference if 431 the information is available at the point where the error is 432 detected. 434 4.1. Security Processing for an Outgoing Message 436 This section describes the procedure followed by the Transport 437 Security Model. 439 The parameters needed for generating a message are supplied to the 440 Security Model by the Message Processing Model via the 441 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 442 Subsystem architectural extension has added the transportDomain, 443 transportAddress, and tmStateReference parameters to the original 444 RFC3411 ASIs. 446 statusInformation = -- success or errorIndication 447 generateRequestMsg( 448 IN messageProcessingModel -- typically, SNMP version 449 IN globalData -- message header, admin data 450 IN maxMessageSize -- of the sending SNMP entity 451 IN transportDomain -- (NEW) specified by application 452 IN transportAddress -- (NEW) specified by application 453 IN securityModel -- for the outgoing message 454 IN securityEngineID -- authoritative SNMP entity 455 IN securityName -- on behalf of this principal 456 IN securityLevel -- Level of Security requested 457 IN scopedPDU -- message (plaintext) payload 458 OUT securityParameters -- filled in by Security Module 459 OUT wholeMsg -- complete generated message 460 OUT wholeMsgLength -- length of generated message 461 OUT tmStateReference -- (NEW) transport info 462 ) 464 statusInformation = -- success or errorIndication 465 generateResponseMsg( 466 IN messageProcessingModel -- typically, SNMP version 467 IN globalData -- message header, admin data 468 IN maxMessageSize -- of the sending SNMP entity 469 IN transportDomain -- (NEW) specified by application 470 IN transportAddress -- (NEW) specified by application 471 IN securityModel -- for the outgoing message 472 IN securityEngineID -- authoritative SNMP entity 473 IN securityName -- on behalf of this principal 474 IN securityLevel -- Level of Security requested 475 IN scopedPDU -- message (plaintext) payload 476 IN securityStateReference -- reference to security state 477 -- information from original 478 -- request 479 OUT securityParameters -- filled in by Security Module 480 OUT wholeMsg -- complete generated message 481 OUT wholeMsgLength -- length of generated message 482 OUT tmStateReference -- (NEW) transport info 483 ) 485 4.2. securityLevel 487 For an incoming message, the Message Processing Model specifies the 488 requested securityLevel to the Security Model. When the Transport 489 Security Model processes an incoming message, if the securityLevel 490 reported by the Transport Model in the cache is less than the 491 securityLevel requested via the processIncomingMsg ASI, it discards 492 the message, and notifies the Message Processing Model. 494 4.3. Elements of Procedure for Outgoing Messages 496 1) If there is a securityStateReference, then this is a response 497 message. Extract transportDomain, transportAddress, securityName, 498 securityLevel, securityModel, and tmStateReference from the cache. 499 The cachedSecurityData for this message can now be discarded. Set 500 the tmSameSession parameter in the tmStateReference cache to true. 502 2) If there is no securityStateReference, then find or create an 503 entry in a Local Configuration Datastore containing the provided 504 transportDomain, transportAddress, securityName, securityLevel, and 505 securityModel, create a tmStateReference to reference the entry. 507 3) Fill in the securityParameters with a zero-length OCTET STRING 508 ('0400'). 510 4) Combine the message parts into a wholeMsg and calculate 511 wholeMsgLength. 513 5) The wholeMsg, wholeMsgLength, securityParameters and 514 tmStateReference are returned to the calling Message Processing Model 515 with the statusInformation set to success. 517 5. Processing an Incoming SNMP Message 519 An error indication may return an OID and value for an incremented 520 counter and a value for securityLevel, and values for contextEngineID 521 and contextName for the counter, and the securityStateReference if 522 the information is available at the point where the error is 523 detected. 525 5.1. Security Processing for an Incoming Message 527 This section describes the procedure followed by the Transport 528 Security Model whenever it receives an incoming message from a 529 Message Processing Model. The abstract service primitive from a 530 Message Processing Model to the Security Subsystem for a received 531 message is: 533 statusInformation = -- errorIndication or success 534 -- error counter OID/value if error 535 processIncomingMsg( 536 IN messageProcessingModel -- typically, SNMP version 537 IN maxMessageSize -- from the received message 538 IN securityParameters -- from the received message 539 IN securityModel -- from the received message 540 IN securityLevel -- from the received message 541 IN wholeMsg -- as received on the wire 542 IN wholeMsgLength -- length as received on the wire 543 IN tmStateReference -- (NEW) from the Transport Model 544 OUT securityEngineID -- authoritative SNMP entity 545 OUT securityName -- identification of the principal 546 OUT scopedPDU, -- message (plaintext) payload 547 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 548 OUT securityStateReference -- reference to security state 549 ) -- information, needed for response 551 5.2. Elements of Procedure for Incoming Messages 553 1) Set the securityEngineID to the local snmpEngineID. 555 2) If the received securityParameters is not a zero-length OCTET 556 STRING, then the snmpInASNParseErrs counter [RFC3418] is incremented, 557 and an error indication (parseError) is returned to the calling 558 module, and Security Model processing stops for this message. 560 3) If tmStateReference does not refer to a cache containing values 561 for securityName and securityLevel, then the tsmInvalidCache counter 562 is incremented, an error indication is returned to the calling 563 module, and Security Model processing stops for this message. 565 4) Extract the value of securityName from the cache referenced by 566 tmStateReference. 568 5) The scopedPDU component is extracted from the wholeMsg. 570 6) The maxSizeResponseScopedPDU is calculated. This is the maximum 571 size allowed for a scopedPDU for a possible Response message. 573 7) Compare the value of securityLevel in the cache referenced by 574 tmStateReference to the value of the securityLevel parameter passed 575 in the processIncomingMsg service primitive. If the parameter 576 specifies privacy (Priv), and the cache specifies no privacy (noPriv) 577 was provided by the Transport Model, or the parameter specifies 578 authentication (auth) and the cache specifies no authentication 579 (noAuth) was provided by the Transport Model, then the 580 tsmInadequateSecurity counter is incremented, and an error indication 581 (unsupportedSecurityLevel) together with the OID and value of the 582 incremented counter is returned to the calling module. 584 8) The information in the tmStateReference may be saved, in an 585 implementation-dependent manner, in a Local Configuration Datastore 586 (LCD) for subsequent usage. 588 9)The security data is cached as cachedSecurityData, so that a 589 possible response to this message can use the same security 590 parameters. Then securityStateReference is set for subsequent 591 reference to this cached data. For Transport Security Model, the 592 securityStateReference should include a reference to the 593 tmStateReference cache. 595 10) The statusInformation is set to success and a return is made to 596 the calling module passing back the OUT parameters as specified in 597 the processIncomingMsg primitive. 599 6. Overview 601 This MIB module provides management of the Transport Security Model. 602 It defines some needed textual conventions, and some statistics. 604 6.1. Structure of the MIB Module 606 Objects in this MIB module are arranged into subtrees. Each subtree 607 is organized as a set of related objects. The overall structure and 608 assignment of objects to their subtrees, and the intended purpose of 609 each subtree, is shown below. 611 6.2. The tsmStats Subtree 613 This subtree contains counters specific to the Transport Security 614 Model, that provide information for identifying fault conditions. 616 6.3. Relationship to Other MIB Modules 618 Some management objects defined in other MIB modules are applicable 619 to an entity implementing the Transport Security Model In particular, 620 it is assumed that an entity implementing the Transport Security 621 Model will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK- 622 MIB [RFC3411]. 624 6.3.1. Relationship to the SNMPv2-MIB 626 The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being 627 mandatory for all systems, and the objects apply to the entity as a 628 whole. The 'system' group provides identification of the management 629 entity and certain other system-wide data. The snmpInASNParseErrs 630 counter is incremented during the elements of procedure. The SNMP- 631 TRANSPORT-SM-MIB does not duplicate those objects. 633 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB 635 The SNMP-FRAMEWORK-MIB provides definitions for the concepts of 636 SnmpEngineID, enumeration of Message Processing Models, Security 637 Models and Security Levels, and object definitions for snmpEngineID 638 These are important for implementing the Transport Security Model, 639 but are not needed to implement the SNMP-TRANSPORT-SM-MIB. 641 6.3.3. MIB Modules Required for IMPORTS 643 The following MIB module imports items from [RFC2578] and [RFC2580]. 645 7. MIB module definition 647 SNMP-TRANSPORT-SM-MIB DEFINITIONS ::= BEGIN 649 IMPORTS 650 MODULE-IDENTITY, OBJECT-TYPE, 651 snmpModules, Counter32 652 FROM SNMPv2-SMI 653 MODULE-COMPLIANCE, OBJECT-GROUP 654 FROM SNMPv2-CONF 655 ; 657 tsmMIB MODULE-IDENTITY 658 LAST-UPDATED "200701250000Z" 659 ORGANIZATION "ISMS Working Group" 660 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 661 Subscribe: isms-request@lists.ietf.org 663 Chairs: 664 Juergen Quittek 665 NEC Europe Ltd. 666 Network Laboratories 667 Kurfuersten-Anlage 36 668 69115 Heidelberg 669 Germany 670 +49 6221 90511-15 671 quittek@netlab.nec.de 673 Juergen Schoenwaelder 674 International University Bremen 675 Campus Ring 1 676 28725 Bremen 677 Germany 678 +49 421 200-3587 679 j.schoenwaelder@iu-bremen.de 681 Editor: 682 David Harrington 683 Huawei Technologies USA 684 1700 Alma Dr. 685 Plano TX 75075 686 USA 687 +1 603-436-8634 688 ietfdbh@comcast.net 689 " 690 DESCRIPTION "The Transport Security Model MIB 692 Copyright (C) The IETF Trust (2007). This 693 version of this MIB module is part of RFC XXXX; 694 see the RFC itself for full legal notices. 695 -- NOTE to RFC editor: replace XXXX with actual RFC number 696 -- for this document and remove this note 697 " 699 REVISION "200701250000Z" 700 DESCRIPTION "The initial version, published in RFC XXXX. 701 -- NOTE to RFC editor: replace XXXX with actual RFC number 702 -- for this document and remove this note 703 " 705 ::= { snmpModules xxxx } 706 -- RFC Ed.: replace xxxx with IANA-assigned number and 707 -- remove this note 709 -- ---------------------------------------------------------- -- 710 -- subtrees in the SNMP-TRANSPORT-SM-MIB 711 -- ---------------------------------------------------------- -- 713 tsmNotifications OBJECT IDENTIFIER ::= { tsmMIB 0 } 714 tsmMIBObjects OBJECT IDENTIFIER ::= { tsmMIB 1 } 715 tsmConformance OBJECT IDENTIFIER ::= { tsmMIB 2 } 717 -- ------------------------------------------------------------- 718 -- Objects 719 -- ------------------------------------------------------------- 721 -- Statistics for the Transport Security Model 723 tsmStats OBJECT IDENTIFIER ::= { tsmMIBObjects 1 } 725 tsmInvalidCache OBJECT-TYPE 726 SYNTAX Counter32 727 MAX-ACCESS read-only 728 STATUS current 729 DESCRIPTION "The number of messages dropped because the 730 tmStateReference referred to an invalid cache. 732 This value is not persistent across reboots. 733 " 734 ::= { tsmStats 1 } 736 tsmInadequateSecurity OBJECT-TYPE 737 SYNTAX Counter32 738 MAX-ACCESS read-only 739 STATUS current 740 DESCRIPTION "The number of incoming messages dropped because 741 the actual securityLevel provided was less than 742 the requested securityLevel. 744 This value is not persistent across reboots. 745 " 746 ::= { tsmStats 2 } 748 -- ------------------------------------------------------------- 749 -- tsmMIB - Conformance Information 750 -- ------------------------------------------------------------- 751 tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } 753 tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } 755 -- ------------------------------------------------------------- 756 -- Units of conformance 757 -- ------------------------------------------------------------- 758 tsmGroup OBJECT-GROUP 759 OBJECTS { 760 tsmInvalidCache, 761 tsmInadequateSecurity 762 } 763 STATUS current 764 DESCRIPTION "A collection of objects for maintaining 765 information of an SNMP engine which implements 766 the SNMP Transport Security Model. 767 " 769 ::= { tsmGroups 2 } 771 -- ------------------------------------------------------------- 772 -- Compliance statements 773 -- ------------------------------------------------------------- 775 tsmCompliance MODULE-COMPLIANCE 776 STATUS current 777 DESCRIPTION 778 "The compliance statement for SNMP engines that support 779 the SNMP-TRANSPORT-SM-MIB" 780 MODULE 781 MANDATORY-GROUPS { tsmGroup } 782 ::= { tsmCompliances 1 } 784 END 786 8. Security Considerations 788 This document describes a Security Model that permits SNMP to utilize 789 security services provided through an SNMP Transport Model. The 790 Transport Security Model relies on Transport Models for mutual 791 authentication, binding of keys, confidentiality and integrity. The 792 security threats and how those threats are mitigated should be 793 covered in detail in the specification of the Transport Model and the 794 underlying secure transport. 796 Transport Security Model relies on a Transport Model to provide an 797 authenticated principal for mapping to securityName, and an assertion 798 for mapping to securityLevel. 800 The Transport Security Model is called a Security Model to be 801 compatible with the RFC3411 architecture. However, this Security 802 Model provides no security itself. It SHOULD always be used with a 803 Transport Model that provides security, but this is a run-time 804 decision of the operator or management application, or a 805 configuration decision of an operator. 807 8.1. MIB module security 809 There are no management objects defined in this MIB module that have 810 a MAX-ACCESS clause of read-write and/or read-create. So, if this 811 MIB module is implemented correctly, then there is no risk that an 812 intruder can alter or create any management objects of this MIB 813 module via direct SNMP SET operations. 815 Some of the readable objects in this MIB module (i.e., objects with a 816 MAX-ACCESS other than not-accessible) may be considered sensitive or 817 vulnerable in some network environments. It is thus important to 818 control even GET and/or NOTIFY access to these objects and possibly 819 to even encrypt the values of these objects when sending them over 820 the network via SNMP. These are the tables and objects and their 821 sensitivity/vulnerability: 823 o tsmInvalidCache and tsmInadequateSecurity may make it easier for 824 an attacker to detect vulnerabilities. 826 SNMP versions prior to SNMPv3 did not include adequate security. 827 Even if the network itself is secure (for example by using IPsec), 828 even then, there is no control as to who on the secure network is 829 allowed to access and GET/SET (read/change/create/delete) the objects 830 in this MIB module. 832 It is RECOMMENDED that implementers consider the security features as 833 provided by the SNMPv3 framework (see [RFC3410] section 8), including 834 full support for the USM and Transport Security Model cryptographic 835 mechanisms (for authentication and privacy). 837 Further, deployment of SNMP versions prior to SNMPv3 is NOT 838 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 839 enable cryptographic security. It is then a customer/operator 840 responsibility to ensure that the SNMP entity giving access to an 841 instance of this MIB module is properly configured to give access to 842 the objects only to those principals (users) that have legitimate 843 rights to indeed GET or SET (change/create/delete) them. 845 9. IANA Considerations 847 IANA is requested to assign: 849 1. an SMI number under snmpModules, for the MIB module in this 850 document, 852 2. a value, preferably 4, to identify the Transport Security Model, 853 in the Security Models registry at 854 http://www.iana.org/assignments/snmp-number-spaces. This should 855 result in the following table of values: 857 Value Description References 858 ----- ----------- ---------- 859 0 reserved for 'any' [RFC2571, RFC3411] 860 1 reserved for SNMPv1 [RFC2571, RFC3411] 861 2 reserved for SNMPv2c [RFC2571, RFC3411] 862 3 User-Based Security Model (USM) [RFC2571, RFC3411] 863 YY Transport Security Model (TSM) [RFCXXXX] 865 -- NOTE to RFC editor: replace XXXX with actual RFC number 866 -- for this document and remove this note 867 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 868 throughout this document and remove this note. 870 10. References 872 10.1. Normative References 874 [RFC2119] Bradner, S., "Key words for use in RFCs to 875 Indicate Requirement Levels", BCP 14, RFC 2119, 876 March 1997. 878 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 879 Schoenwaelder, Ed., "Structure of Management 880 Information Version 2 (SMIv2)", STD 58, 881 RFC 2578, April 1999. 883 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 884 Schoenwaelder, Ed., "Textual Conventions for 885 SMIv2", STD 58, RFC 2579, April 1999. 887 [RFC2580] McCloghrie, K., Perkins, D., and J. 888 Schoenwaelder, "Conformance Statements for 889 SMIv2", STD 58, RFC 2580, April 1999. 891 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 892 Architecture for Describing Simple Network 893 Management Protocol (SNMP) Management 894 Frameworks", STD 62, RFC 3411, December 2002. 896 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 897 Wijnen, "Message Processing and Dispatching for 898 the Simple Network Management Protocol (SNMP)", 899 STD 62, RFC 3412, December 2002. 901 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 902 Network Management Protocol (SNMP) 903 Applications", STD 62, RFC 3413, December 2002. 905 [RFC3418] Presuhn, R., "Management Information Base (MIB) 906 for the Simple Network Management Protocol 907 (SNMP)", STD 62, RFC 3418, December 2002. 909 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 910 Subsystem for the Simple Network Management 911 Protocol (SNMP)", draft-ietf-isms-tmsm-07 (work 912 in progress), March 2007. 914 10.2. Informative References 916 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 917 Stewart, "Introduction and Applicability 918 Statements for Internet-Standard Management 919 Framework", RFC 3410, December 2002. 921 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 922 Security Model (USM) for version 3 of the 923 Simple Network Management Protocol (SNMPv3)", 924 STD 62, RFC 3414, December 2002. 926 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 927 Wijnen, "Coexistence between Version 1, Version 928 2, and Version 3 of the Internet-standard 929 Network Management Framework", BCP 74, 930 RFC 3584, August 2003. 932 Appendix A. Notification Tables Configuration 934 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 935 configure notification originators with the destinations to which 936 notifications should be sent. 938 Most of the configuration is security-model-independent and 939 transport-model-independent. 941 The values we will use in the examples for the five model-independent 942 security and transport parameters are: 944 transportDomain = snmpSSHDomain 946 transportAddress = 192.0.2.1:162 948 securityModel = Transport Security Model 950 securityName = sampleUser 952 securityLevel = authPriv 954 The following example will configure the Notification Originator to 955 send informs to a Notification Receiver at host 192.0.2.1 port 162 956 using the securityName "sampleUser". The columns marked with a "*" 957 are the items that are Security Model or Transport Model specific. 959 The configuration for the "sampleUser" settings in the SNMP-VIEW- 960 BASED-ACM-MIB objects are not shown here for brevity. First we 961 configure which type of notification should be sent for this taglist 962 (toCRTag). In this example, we choose to send an Inform. 963 snmpNotifyTable row: 964 snmpNotifyName CRNotif 965 snmpNotifyTag toCRTag 966 snmpNotifyType inform 967 snmpNotifyStorageType nonVolatile 968 snmpNotifyColumnStatus createAndGo 970 Then we configure a transport address to which notifications 971 associated with this taglist should be sent, and we specify which 972 snmpTargetParamsEntry should be used (toCR) when sending to this 973 transport address. 974 snmpTargetAddrTable row: 975 snmpTargetAddrName toCRAddr 976 * snmpTargetAddrTDomain snmpSSHDomain 977 snmpTargetAddrTAddress 192.0.2.1:162 978 snmpTargetAddrTimeout 1500 979 snmpTargetAddrRetryCount 3 980 snmpTargetAddrTagList toCRTag 981 snmpTargetAddrParams toCR (must match below) 982 snmpTargetAddrStorageType nonVolatile 983 snmpTargetAddrColumnStatus createAndGo 985 Then we configure which principal at the host should receive the 986 notifications associated with this taglist. Here we choose 987 "sampleUser", who uses the Transport Security Model. 989 snmpTargetParamsTable row: 990 snmpTargetParamsName toCR 991 snmpTargetParamsMPModel SNMPv3 992 * snmpTargetParamsSecurityModel TransportSecurityModel 993 snmpTargetParamsSecurityName "sampleUser" 994 snmpTargetParamsSecurityLevel authPriv 995 snmpTargetParamsStorageType nonVolatile 996 snmpTargetParamsRowStatus createAndGo 998 A.1. Transport Security Model Processing 1000 The Transport Security Model is called using the generateRequestMsg() 1001 ASI, with the following parameters (* are from the above tables): 1003 statusInformation = -- success or errorIndication 1004 generateRequestMsg( 1005 IN messageProcessingModel -- *snmpTargetParamsMPModel 1006 IN globalData -- message header, admin data 1007 IN maxMessageSize -- of the sending SNMP entity 1008 IN transportDomain -- *snmpTargetAddrTDomain 1009 IN transportAddress -- *snmpTargetAddrTAddress 1010 IN securityModel -- *snmpTargetParamsSecurityModel 1011 IN securityEngineID -- immaterial; TSM will ignore. 1012 IN securityName -- snmpTargetParamsSecurityName 1013 IN securityLevel -- *snmpTargetParamsSecurityLevel 1014 IN scopedPDU -- message (plaintext) payload 1015 OUT securityParameters -- filled in by Security Module 1016 OUT wholeMsg -- complete generated message 1017 OUT wholeMsgLength -- length of generated message 1018 OUT tmStateReference -- reference to transport info 1019 ) 1021 The Transport Security Model will determine the Transport Model based 1022 on the snmpTargetAddrTDomain. The selected Transport Model will 1023 select the appropriate transport "session" using the 1024 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1025 snmpTargetParamsSecurityLevel. 1027 Appendix B. Change Log 1029 From -03- to -04- 1031 Editorial changes requested by Tom Petch, to clarify behavior with 1032 SNMPv1/v2c 1034 Added early discussion of how TSM fits into the architecture to 1035 clarify behavior when RFC3584 security models are co-resident. 1037 Editorial changes requested by Bert Wijnen, to eliminate version- 1038 specific discussions. 1040 Removed sections on version-specific message formats. 1042 Removed discussion of SNMPv3 in Motivation section. 1044 Added discussion of request/response session matching. 1046 From -02- to -03- 1048 Editorial changes suggested by Juergen Schoenwaelder 1050 Capitalized Transport Models, Security Models, and Message 1051 Processing Models, to be consistent with RFC341x conventions. 1053 Eliminated some text that duplicated RFC3412, especially in 1054 Elements of Procedure. 1056 Changed the encoding of msgSecurityParameters 1058 Marked the (NEW) fields added to existing ASIs 1060 Modified text intro discussing relationships to other MIB modules. 1062 From -01- to -02- 1064 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1065 waiting for assignment 1067 cleaned up elements of procedure [todo]s 1069 use the same errorIndication as USM for unsupportedSecurityLevel 1071 fixed syntax of tsmInadequateSecurity counter 1073 changed the "can and will use" the same security parameters to 1074 "can use", to allow responses that have different security 1075 parameters than the request. 1077 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1079 cleaned up "MIB Modules Required for IMPORTS" 1081 From -00- to -01- 1083 made the Transport Model not know anything about the Security 1084 Model. 1086 modified the elements of procedure sections, given the 1087 implications of this change. 1089 simplified elements of procedure, removing most info specified in 1090 architecture/subsystem definitions. 1092 rethought the coexistence section 1094 noted the implications of the Transport Security Model on 1095 isAccessAllowed() 1097 modified all text related to the LCD. 1099 removed most of the MIB (now the TSM has no configuration 1100 parameters). 1102 added counters needed to support elements of procedure 1104 renamed MIB module, and registered under snmpModules 1106 updated IANA and Security Considerations 1108 updated references. 1110 modified the notification configurations. 1112 From SSHSM-04- to Transport-security-model-00 1114 added tsmUserTable 1116 updated Appendix - Notification Tables Configuration 1118 remove open/closed issue appendices 1120 changed tmSessionReference to tmStateReference 1122 Author's Address 1124 David Harrington 1125 Huawei Technologies (USA) 1126 1700 Alma Dr. Suite 100 1127 Plano, TX 75075 1128 USA 1130 Phone: +1 603 436 8634 1131 EMail: dharrington@huawei.com 1133 Full Copyright Statement 1135 Copyright (C) The IETF Trust (2007). 1137 This document is subject to the rights, licenses and restrictions 1138 contained in BCP 78, and except as set forth therein, the authors 1139 retain all their rights. 1141 This document and the information contained herein are provided on an 1142 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1143 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1144 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1145 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1146 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1147 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1149 Intellectual Property 1151 The IETF takes no position regarding the validity or scope of any 1152 Intellectual Property Rights or other rights that might be claimed to 1153 pertain to the implementation or use of the technology described in 1154 this document or the extent to which any license under such rights 1155 might or might not be available; nor does it represent that it has 1156 made any independent effort to identify any such rights. Information 1157 on the procedures with respect to rights in RFC documents can be 1158 found in BCP 78 and BCP 79. 1160 Copies of IPR disclosures made to the IETF Secretariat and any 1161 assurances of licenses to be made available, or the result of an 1162 attempt made to obtain a general license or permission for the use of 1163 such proprietary rights by implementers or users of this 1164 specification can be obtained from the IETF on-line IPR repository at 1165 http://www.ietf.org/ipr. 1167 The IETF invites any interested party to bring to its attention any 1168 copyrights, patents or patent applications, or other proprietary 1169 rights that may cover technology that may be required to implement 1170 this standard. Please address the information to the IETF at 1171 ietf-ipr@ietf.org. 1173 Acknowledgement 1175 Funding for the RFC Editor function is provided by the IETF 1176 Administrative Support Activity (IASA).