idnits 2.17.1 draft-ietf-isms-transport-security-model-03.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 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1129. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1135. 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 1001 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 (February 23, 2007) is 6271 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 875, but not defined ** Obsolete undefined reference: RFC 2571 (Obsoleted by RFC 3411) == Missing Reference: 'RFCXXXX' is mentioned on line 876, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-06 -- 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 February 23, 2007 5 Expires: August 27, 2007 7 Transport Security Model for SNMP 8 draft-ietf-isms-transport-security-model-03 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 August 27, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo describes a Transport Security Model for the Simple Network 42 Management Protocol. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. The Internet-Standard Management Framework . . . . . . . . 3 48 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 52 2. How Transport Security Model Fits in the Architecture . . . . 5 53 2.1. Security Capabilities of this Model . . . . . . . . . . . 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. msgFlags . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1.2. msgSecurityParameters . . . . . . . . . . . . . . . . 9 64 3.2. Cached Information and References . . . . . . . . . . . . 9 65 3.2.1. securityStateReference . . . . . . . . . . . . . . . . 10 66 3.2.2. tmStateReference . . . . . . . . . . . . . . . . . . . 10 67 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 68 4.1. Security Processing for an Outgoing Message . . . . . . . 10 69 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 11 70 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 12 71 5.1. Security Processing for an Incoming Message . . . . . . . 12 72 5.2. Elements of Procedure for Incoming Messages . . . . . . . 13 73 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 14 75 6.2. The tsmStats Subtree . . . . . . . . . . . . . . . . . . . 14 76 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 14 77 6.3.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 14 78 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 14 79 6.3.3. MIB Modules Required for IMPORTS . . . . . . . . . . . 14 80 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 87 Appendix A. Notification Tables Configuration . . . . . . . . . . 21 88 A.1. Transport Security Model Processing . . . . . . . . . . . 22 89 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 This memo describes a Transport Security Model for the Simple Network 94 Management Protocol, for use with secure Transport Models in the 95 Transport Subsystem [I-D.ietf-isms-tmsm]. 97 This memo also defines a portion of the Management Information Base 98 (MIB) for use with network management protocols in TCP/IP based 99 internets. In particular it defines objects for monitoring and 100 managing the Transport Security Model for SNMP. 102 It is important to understand the SNMP architecture and the 103 terminology of the architecture to understand where the Transport 104 Security Model described in this memo fits into the architecture and 105 interacts with other subsystems and models within the architecture. 106 It is expected that reader will have also read and understood RFC3411 107 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418 108 [RFC3418]. 110 1.1. The Internet-Standard Management Framework 112 For a detailed overview of the documents that describe the current 113 Internet-Standard Management Framework, please refer to section 7 of 114 RFC 3410 [RFC3410]. 116 Managed objects are accessed via a virtual information store, termed 117 the Management Information Base or MIB. MIB objects are generally 118 accessed through the Simple Network Management Protocol (SNMP). 119 Objects in the MIB are defined using the mechanisms defined in the 120 Structure of Management Information (SMI). This memo specifies a MIB 121 module that is compliant to the SMIv2, which is described in STD 58, 122 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 123 [RFC2580]. 125 1.2. Conventions 127 The terms "manager" and "agent" are not used in this document, 128 because in the RFC 3411 architecture, all SNMP entities have the 129 capability of acting as either manager or agent or both depending on 130 the SNMP applications included in the engine. Where distinction is 131 required, the application names of Command Generator, Command 132 Responder, Notification Originator, Notification Receiver, and Proxy 133 Forwarder are used. See "SNMP Applications" [RFC3413] for further 134 information. 136 While security protocols frequently refer to a user, the terminology 137 used in RFC3411 [RFC3411] and in this memo is "principal". A 138 principal is the "who" on whose behalf services are provided or 139 processing takes place. A principal can be, among other things, an 140 individual acting in a particular role; a set of individuals, with 141 each acting in a particular role; an application or a set of 142 applications, or a combination of these within an administrative 143 domain. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 1.3. Modularity 151 The reader is expected to have read and understood the description of 152 the SNMP architecture, as defined in [RFC3411],and the architecture 153 extension specified in "Transport Subsystem for the Simple Network 154 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 155 external "lower layer transport" protocols to provide message 156 security, tied into the SNMP architecture through the Transport 157 Subsystem. The Transport Security Model is designed to work with 158 such lower-layer secure Transport Models. 160 In keeping with the RFC 3411 design decisions to use self-contained 161 documents, this memo includes the elements of procedure plus 162 associated MIB objects which are needed for processing the Transport 163 Security Model for SNMP. These MIB objects SHOULD not be referenced 164 in other documents. This allows the Transport Security Model to be 165 designed and documented as independent and self-contained, having no 166 direct impact on other modules, and allowing this module to be 167 upgraded and supplemented as the need arises, and to move along the 168 standards track on different time-lines from other modules. 170 This modularity of specification is not meant to be interpreted as 171 imposing any specific requirements on implementation. 173 1.4. Motivation 175 Version 3 of the Simple Network Management Protocol (SNMPv3) added 176 security to the previous versions of the protocol. The User-based 177 Security Model (USM) [RFC3414] was designed to be independent of 178 other existing security infrastructures, to ensure it could function 179 when third party authentication services were not available, such as 180 in a broken network. As a result, USM typically utilizes a separate 181 user and key management infrastructure. Operators have reported that 182 deploying another user and key management infrastructure in order to 183 use SNMPv3 is a reason for not deploying SNMPv3 at this point in 184 time. 186 This memo describes a Security Model that will make use of Transport 187 Models that rely on lower layer secure transports and existing and 188 commonly deployed security infrastructures. This Security Model is 189 designed to meet the security and operational needs of network 190 administrators, maximize usability in operational environments to 191 achieve high deployment success and at the same time minimize 192 implementation and deployment costs to minimize the time until 193 deployment is possible. 195 1.5. Constraints 197 The design of this SNMP Security Model is also influenced by the 198 following constraints: 199 1. When the requirements of effective management in times of network 200 stress are inconsistent with those of security, the design of 201 this model gives preference to effective management. 202 2. In times of network stress, the security protocol and its 203 underlying security mechanisms SHOULD NOT depend upon the ready 204 availability of other network services (e.g., Network Time 205 Protocol (NTP) or Authentication, Authorization, and Accounting 206 (AAA) protocols). 207 3. When the network is not under stress, the Security Model and its 208 underlying security mechanisms MAY depend upon the ready 209 availability of other network services. 210 4. It may not be possible for the Security Model to determine when 211 the network is under stress. 212 5. A Security Model should require no changes to the SNMP 213 architecture. 214 6. A Security Model should require no changes to the underlying 215 security protocol. 217 2. How Transport Security Model Fits in the Architecture 219 The Transport Security Model is designed to fit into the RFC3411 220 architecture as a Security Model in the Security Subsystem, and to 221 utilize the services of a secure Transport Model. 223 The Transport Model of an SNMP engine will perform the translation 224 between transport-specific security parameters and the SNMP-specific, 225 model-independent parameters securityName and securityLevel. To 226 maintain the RFC3411 modularity, the Transport Model does not know 227 which securityModel will be used for an incoming message; the Message 228 Processing Model will determine the securityModel to be used, in a 229 Message Processing Model dependent manner. In an SNMPv3 message 230 [RFC3412], the Transport Security Model should be specified in the 231 message header. 233 2.1. Security Capabilities of this Model 235 2.1.1. Threats 237 The Transport Security Model, when used with suitable secure 238 Transport Models, provides protection against the threats identified 239 by the RFC 3411 architecture [RFC3411]. 241 Which threats are addressed depends on the Transport Model. The 242 Transport Security Model does not address any threats itself, but 243 delegates that responsibility to a secure Transport Model. 245 The Transport Security Model is called a Security Model to be 246 compatible with the RFC3411 architecture. However, this Security 247 Model does not provide security mechanisms such as authentication and 248 encryption itself, so it SHOULD always be used with a Transport Model 249 that provides appropriate security. 251 2.1.2. Security Levels 253 The RFC 3411 architecture recognizes three levels of security: 254 - without authentication and without privacy (noAuthNoPriv) 255 - with authentication but without privacy (authNoPriv) 256 - with authentication and with privacy (authPriv) 258 The model-independent securityLevel parameter is used to request 259 specific levels of security for outgoing messages, and to assert that 260 specific levels of security were applied during the transport and 261 processing of incoming messages. 263 The transport layer algorithms used to provide security SHOULD NOT be 264 exposed to the Transport Security Model, as the Transport Security 265 Model has no mechanisms by which it can test whether an assertion 266 made by a Transport Model is accurate. 268 The Transport Security Model trusts that the underlying secure 269 transport connection has been properly configured to support security 270 characteristics at least as strong as requested in securityLevel. 272 2.2. No Sessions 274 The Transport Security Model will associate state regarding each 275 message and each known remote engine with a single combination of 276 transportDomain, transportAddress, securityName, securityModel, and 277 securityLevel. 279 Some Transport Models will utilize sessions to maintain long-lived 280 state; others will use stateless transport. For reasons of module 281 independence, the Transport Security Model will make no assumptions 282 about there being a session of any kind. Each message may be totally 283 independent of other messages. Any binding of multiples messages 284 into a session is specific to the Transport Model. There may be 285 circumstances where having an SNMP-specific session provided by a 286 Security Model is useful; such functionality is left to future 287 Security Models. 289 2.3. Coexistence 291 There are two primary factors which determine whether Security Models 292 can coexist. First, there must be a mechanism to select different 293 Security Models at run-time. Second, the processing of one Security 294 Model should not impact the processing of another Security Model. 296 In the RFC3411 architecture, a Message Processing Model determines 297 which Security Model should be called. As of this writing, there are 298 three Message Processing Models and three other Security Models: 299 SNMPv1, SNMPv2c, and the User-based Security Model. 301 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 302 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 303 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 304 message. Since there is no field in the message format that permits 305 specifying a Security Model, RFC3584 message processing does not 306 permit the selection of Security Models other than SNMPv1 or SNMPv2. 307 Therefore, the Transport Security Model can coexist with SNMPv1 and 308 SNMPv2c community-based Security Models, but the Transport Security 309 Model cannot be used with SNMPv1 or SNMPv2c messages. 311 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 312 the securityModel from the msgSecurityModel field of an incoming 313 SNMPv3Message. When the extracted value of msgSecurityModel is 314 transportSecurityModel(YY), security processing is directed to the 315 Transport Security Model. So for an outgoing message secured using 316 the Transport Security Model, msgSecurityModel should be set to 317 transportSecurityModel(YY). 319 The Transport Security Model uses its own MIB module for processing 320 to maintain independence from other Security Models. This allows the 321 Transport Security Model to coexist with other Security Models, such 322 as the User-based Security Model. 324 Note that the Transport Security Model may work with multiple 325 Transport Models, but the isAccessAllowed() primitive only accepts a 326 value for the Security Model, not for Transport Models. As a result, 327 it is not possible to have different access control rules for 328 different Transport Models that use the Transport Security Model. 330 2.4. Security Parameter Passing 332 For outgoing messages, Transport Security Model takes input provided 333 by the SNMP application, converts that information into suitable 334 transport and security parameters in a cache referenced by 335 tmStateReference. The wholeMsg and the tmStateReference are passed 336 to the appropriate Transport Model through a series of APIs, as 337 described in "Transport Subsystem for the Simple Network Management 338 Protocol" [I-D.ietf-isms-tmsm]. 340 For incoming messages, the Transport Model accepts messages from the 341 lower layer transport, and records the transport-related information 342 and security-related information, including a securityName that 343 represents the authenticated identity, and a securityLevel that 344 represents the security features provided during transport, in a 345 cache referenced by tmStateReference. The wholeMsg and the 346 tmStateReference are passed to the appropriate Security Model through 347 a series of APIs, as described in "Transport Subsystem for the Simple 348 Network Management Protocol" [I-D.ietf-isms-tmsm]. 350 For an incoming SNMPv3 message, the Message Processing Model extracts 351 the requested securityLevel from the msgFlags field, and passes this 352 to the Security Model. The Transport Security Model verifies that 353 the securityLevel passed in the cache is at least as strong as the 354 securityLevel passed in the ASI securityLevel parameter. 356 2.5. Notifications and Proxy 358 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 359 management targets, including transportDomain, transportAddress, 360 securityName, securityModel, and securityLevel parameters, for 361 applications such as notifications and proxy. For the Transport 362 Security Model, transport type and address are configured in the 363 snmpTargetAddrTable, and the securityModel, securityName, and 364 securityLevel parameters are configured in the snmpTargetParamsTable. 366 The default approach is for an administrator to statically configure 367 this information to identify the targets authorized to receive 368 notifications or perform proxy. 370 3. Message Formats 372 The syntax of an SNMP message using this Security Model adheres to 373 the message format defined in the version-specific Message Processing 374 Model document (for example [RFC3412]). At the time of this writing, 375 there are three defined message formats - SNMPv1, SNMPv2c, and 376 SNMPv3. The Transport Security Model does not work with SNMPv1 and 377 SNMPv2c for reasons described above, so this memo only deals with 378 SNMPv3 messages. 380 The processing is compatible with the RFC 3412 primitives, 381 generateRequestMsg() and processIncomingMsg(), that show the data 382 flow between the Message Processor and the Security Model. 384 3.1. SNMPv3 Message Fields 386 The following describes how the Transport Security Model treats 387 certain fields in an SNMPv3Message: The SNMPv3Message SEQUENCE is 388 defined in [RFC3412]. 390 3.1.1. msgFlags 392 To maintain the separation between subsystems, the Transport Security 393 Model does not modify Message Model dependent fields. As a result, 394 msgFlags in an SNMPv3 message reflects the requested securityLevel, 395 not the actual securityLevel applied to the message by the Transport 396 Model. 398 When the Security Model processes an incoming message, it compares 399 the securityLevel provided by the Message Processing Model to the 400 securityLevel reported by the Transport Model in tmStateReference. 401 If the securityLevel reported by the Transport Model is less than the 402 requested securityLevel, it discards the message, and notifies the 403 Message Processing Model. 405 3.1.2. msgSecurityParameters 407 Since message security is provided by a "lower layer", and the 408 securityName parameter is always determined by the Transport Model 409 from the lower layer authentication method, the SNMP message does not 410 need to carry message security parameters within the 411 msgSecurityParameters field. The field msgSecurityParameters MUST be 412 set to a zero-length OCTET STRING. 414 3.2. Cached Information and References 416 The RFC3411 architecture uses caches to store dynamic model-specific 417 information, and uses references in the ASIs to indicate in a model- 418 independent manner which cached information must flow between 419 subsystems. 421 There are two levels of state that may need to be maintained: the 422 security state in a request-response pair, and potentially long-term 423 state relating to transport and security. This document describes 424 caches, and differentiates the tmStateReference from the 425 securityStateReference, but how this is represented internally is an 426 implementation decision. 428 As a general rule, if state information is available when a message 429 being processed gets discarded, the state related to that message 430 should also be discarded, and if state information is available when 431 a relationship between engines is severed, such as the closing of a 432 transport session, the state information for that relationship might 433 also be discarded. 435 3.2.1. securityStateReference 437 The securityStateReference parameter is defined in RFC3411. A sample 438 model-specific cache can be found in RFC3414. 440 If a Transport Model connection is closed between the time a Request 441 is received and a Response message is being prepared, then the 442 Response message MAY be discarded. 444 3.2.2. tmStateReference 446 For each transport session, information about the message security is 447 stored in a cache to pass model- and mechanism-specific parameters. 448 The state referenced by tmStateReference may be saved across multiple 449 messages, in a Local Configuration Datastore (LCD), as compared to 450 securityStateReference which is usually only saved for the life of a 451 request-response pair of messages. 453 The format of the cache and the LCD are implementation-specific. 455 4. Processing an Outgoing Message 457 An error indication may return an OID and value for an incremented 458 counter and a value for securityLevel, and values for contextEngineID 459 and contextName for the counter, and the securityStateReference if 460 the information is available at the point where the error is 461 detected. 463 4.1. Security Processing for an Outgoing Message 465 This section describes the procedure followed by the Transport 466 Security Model. 468 The parameters needed for generating a message are supplied to the 469 Security Model by the Message Processing Model via the 470 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 471 Subsystem architectural extension has added the transportDomain, 472 transportAddress, and tmStateReference parameters to the original 473 RFC3411 ASIs. 475 statusInformation = -- success or errorIndication 476 generateRequestMsg( 477 IN messageProcessingModel -- typically, SNMP version 478 IN globalData -- message header, admin data 479 IN maxMessageSize -- of the sending SNMP entity 480 IN transportDomain -- (NEW) specified by application 481 IN transportAddress -- (NEW) specified by application 482 IN securityModel -- for the outgoing message 483 IN securityEngineID -- authoritative SNMP entity 484 IN securityName -- on behalf of this principal 485 IN securityLevel -- Level of Security requested 486 IN scopedPDU -- message (plaintext) payload 487 OUT securityParameters -- filled in by Security Module 488 OUT wholeMsg -- complete generated message 489 OUT wholeMsgLength -- length of generated message 490 OUT tmStateReference -- (NEW) transport info 491 ) 493 statusInformation = -- success or errorIndication 494 generateResponseMsg( 495 IN messageProcessingModel -- typically, SNMP version 496 IN globalData -- message header, admin data 497 IN maxMessageSize -- of the sending SNMP entity 498 IN transportDomain -- (NEW) specified by application 499 IN transportAddress -- (NEW) specified by application 500 IN securityModel -- for the outgoing message 501 IN securityEngineID -- authoritative SNMP entity 502 IN securityName -- on behalf of this principal 503 IN securityLevel -- Level of Security requested 504 IN scopedPDU -- message (plaintext) payload 505 IN securityStateReference -- reference to security state 506 -- information from original 507 -- request 508 OUT securityParameters -- filled in by Security Module 509 OUT wholeMsg -- complete generated message 510 OUT wholeMsgLength -- length of generated message 511 OUT tmStateReference -- (NEW) transport info 512 ) 514 4.2. Elements of Procedure for Outgoing Messages 516 1) If there is a securityStateReference, then extract 517 transportDomain, transportAddress, securityName, securityLevel, 518 securityModel, and tmStateReference from the cache. The 519 cachedSecurityData for this message can now be discarded. 521 2) If there is no securityStateReference, then find or create an 522 entry in a Local Configuration Datastore containing the provided 523 transportDomain, transportAddress, securityName, securityLevel, and 524 securityModel, and create a tmStateReference to reference the entry. 526 3) Fill in the securityParameters with a zero-length OCTET STRING 527 ('0400'). 529 4) Combine the message parts into a wholeMsg and calculate 530 wholeMsgLength. 532 5) The wholeMsg, wholeMsgLength, securityParameters and 533 tmStateReference are returned to the calling Message Processing Model 534 with the statusInformation set to success. 536 5. Processing an Incoming SNMP Message 538 An error indication may return an OID and value for an incremented 539 counter and a value for securityLevel, and values for contextEngineID 540 and contextName for the counter, and the securityStateReference if 541 the information is available at the point where the error is 542 detected. 544 5.1. Security Processing for an Incoming Message 546 This section describes the procedure followed by the Transport 547 Security Model whenever it receives an incoming message from a 548 Message Processing Model. The abstract service primitive from a 549 Message Processing Model to the Security Subsystem for a received 550 message is: 552 statusInformation = -- errorIndication or success 553 -- error counter OID/value if error 554 processIncomingMsg( 555 IN messageProcessingModel -- typically, SNMP version 556 IN maxMessageSize -- from the received message 557 IN securityParameters -- from the received message 558 IN securityModel -- from the received message 559 IN securityLevel -- from the received message 560 IN wholeMsg -- as received on the wire 561 IN wholeMsgLength -- length as received on the wire 562 IN tmStateReference -- (NEW) from the Transport Model 563 OUT securityEngineID -- authoritative SNMP entity 564 OUT securityName -- identification of the principal 565 OUT scopedPDU, -- message (plaintext) payload 566 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 567 OUT securityStateReference -- reference to security state 568 ) -- information, needed for response 570 5.2. Elements of Procedure for Incoming Messages 572 1) If the messageProcessingModel is SNMPv3, then the securityEngineID 573 is set to the local snmpEngineID, to satisfy the SNMPv3 message 574 processing defined in RFC 3412 section 7.2 13a). 576 2) If the received securityParameters is not a zero-length OCTET 577 STRING, then the snmpInASNParseErrs counter [RFC3418] is incremented, 578 and an error indication (parseError) is returned to the calling 579 module, and Security Model processing stops for this message. 581 3) If tmStateReference does not refer to a cache containing values 582 for securityName and securityLevel, then the tsmInvalidCache counter 583 is incremented, an error indication is returned to the calling 584 module, and Security Model processing stops for this message. 586 4) Extract the value of securityName from the cache referenced by 587 tmStateReference. 589 5) The scopedPDU component is extracted from the wholeMsg. 591 6) The maxSizeResponseScopedPDU is calculated. This is the maximum 592 size allowed for a scopedPDU for a possible Response message. 594 7) Compare the value of securityLevel in the cache referenced by 595 tmStateReference to the value of the securityLevel parameter passed 596 in the processIncomingMsg service primitive. If the parameter 597 specifies privacy (Priv), and the cache specifies no privacy (noPriv) 598 was provided by the Transport Model, or the parameter specifies 599 authentication (auth) and the cache specifies no authentication 600 (noAuth) was provided by the Transport Model, then the 601 tsmInadequateSecurity counter is incremented, and an error indication 602 (unsupportedSecurityLevel) together with the OID and value of the 603 incremented counter is returned to the calling module. 605 8) The information in the tmStateReference may be saved, in an 606 implementation-dependent manner, in a Local Configuration Datastore 607 (LCD) for subsequent usage. 609 9)The security data is cached as cachedSecurityData, so that a 610 possible response to this message can use the same security 611 parameters. Then securityStateReference is set for subsequent 612 reference to this cached data. For Transport Security Model, the 613 securityStateReference should include a reference to the 614 tmStateReference cache. 616 10) The statusInformation is set to success and a return is made to 617 the calling module passing back the OUT parameters as specified in 618 the processIncomingMsg primitive. 620 6. Overview 622 This MIB module provides management of the Transport Security Model. 623 It defines some needed textual conventions, and some statistics. 625 6.1. Structure of the MIB Module 627 Objects in this MIB module are arranged into subtrees. Each subtree 628 is organized as a set of related objects. The overall structure and 629 assignment of objects to their subtrees, and the intended purpose of 630 each subtree, is shown below. 632 6.2. The tsmStats Subtree 634 This subtree contains counters specific to the Transport Security 635 Model, that provide information for identifying fault conditions. 637 6.3. Relationship to Other MIB Modules 639 Some management objects defined in other MIB modules are applicable 640 to an entity implementing the Transport Security Model In particular, 641 it is assumed that an entity implementing the Transport Security 642 Model will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK- 643 MIB [RFC3411]. 645 6.3.1. Relationship to the SNMPv2-MIB 647 The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being 648 mandatory for all systems, and the objects apply to the entity as a 649 whole. The 'system' group provides identification of the management 650 entity and certain other system-wide data. The snmpInASNParseErrs 651 counter is incremented during the elements of procedure. The SNMP- 652 TRANSPORT-SM-MIB does not duplicate those objects. 654 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB 656 The SNMP-FRAMEWORK-MIB provides definitions for the concepts of 657 SnmpEngineID, enumeration of Message Processing Models, Security 658 Models and Security Levels, and object definitions for snmpEngineID 659 These are important for implementing the Transport Security Model, 660 but are not needed to implement the SNMP-TRANSPORT-SM-MIB. 662 6.3.3. MIB Modules Required for IMPORTS 664 The following MIB module imports items from [RFC2578] and [RFC2580]. 666 7. MIB module definition 668 SNMP-TRANSPORT-SM-MIB DEFINITIONS ::= BEGIN 670 IMPORTS 671 MODULE-IDENTITY, OBJECT-TYPE, 672 snmpModules, Counter32 673 FROM SNMPv2-SMI 674 MODULE-COMPLIANCE, OBJECT-GROUP 675 FROM SNMPv2-CONF 676 ; 678 tsmMIB MODULE-IDENTITY 679 LAST-UPDATED "200701250000Z" 680 ORGANIZATION "ISMS Working Group" 681 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 682 Subscribe: isms-request@lists.ietf.org 684 Chairs: 685 Juergen Quittek 686 NEC Europe Ltd. 687 Network Laboratories 688 Kurfuersten-Anlage 36 689 69115 Heidelberg 690 Germany 691 +49 6221 90511-15 692 quittek@netlab.nec.de 694 Juergen Schoenwaelder 695 International University Bremen 696 Campus Ring 1 697 28725 Bremen 698 Germany 699 +49 421 200-3587 700 j.schoenwaelder@iu-bremen.de 702 Editor: 703 David Harrington 704 Huawei Technologies USA 705 1700 Alma Dr. 706 Plano TX 75075 707 USA 708 +1 603-436-8634 709 ietfdbh@comcast.net 710 " 711 DESCRIPTION "The Transport Security Model MIB 712 Copyright (C) The IETF Trust (2007). This 713 version of this MIB module is part of RFC XXXX; 714 see the RFC itself for full legal notices. 715 -- NOTE to RFC editor: replace XXXX with actual RFC number 716 -- for this document and remove this note 717 " 719 REVISION "200701250000Z" 720 DESCRIPTION "The initial version, published in RFC XXXX. 721 -- NOTE to RFC editor: replace XXXX with actual RFC number 722 -- for this document and remove this note 723 " 725 ::= { snmpModules xxxx } 726 -- RFC Ed.: replace xxxx with IANA-assigned number and 727 -- remove this note 729 -- ---------------------------------------------------------- -- 730 -- subtrees in the SNMP-TRANSPORT-SM-MIB 731 -- ---------------------------------------------------------- -- 733 tsmNotifications OBJECT IDENTIFIER ::= { tsmMIB 0 } 734 tsmMIBObjects OBJECT IDENTIFIER ::= { tsmMIB 1 } 735 tsmConformance OBJECT IDENTIFIER ::= { tsmMIB 2 } 737 -- ------------------------------------------------------------- 738 -- Objects 739 -- ------------------------------------------------------------- 741 -- Statistics for the Transport Security Model 743 tsmStats OBJECT IDENTIFIER ::= { tsmMIBObjects 1 } 745 tsmInvalidCache OBJECT-TYPE 746 SYNTAX Counter32 747 MAX-ACCESS read-only 748 STATUS current 749 DESCRIPTION "The number of messages dropped because the 750 tmStateReference referred to an invalid cache. 751 " 752 ::= { tsmStats 1 } 754 tsmInadequateSecurity OBJECT-TYPE 755 SYNTAX Counter32 756 MAX-ACCESS read-only 757 STATUS current 758 DESCRIPTION "The number of incoming messages dropped because 759 the actual securityLevel provided was less than 760 the requested securityLevel. 761 " 762 ::= { tsmStats 2 } 764 -- ------------------------------------------------------------- 765 -- tsmMIB - Conformance Information 766 -- ------------------------------------------------------------- 768 tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } 770 tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } 772 -- ------------------------------------------------------------- 773 -- Units of conformance 774 -- ------------------------------------------------------------- 775 tsmGroup OBJECT-GROUP 776 OBJECTS { 777 tsmInvalidCache, 778 tsmInadequateSecurity 779 } 780 STATUS current 781 DESCRIPTION "A collection of objects for maintaining 782 information of an SNMP engine which implements 783 the SNMP Transport Security Model. 784 " 786 ::= { tsmGroups 2 } 788 -- ------------------------------------------------------------- 789 -- Compliance statements 790 -- ------------------------------------------------------------- 792 tsmCompliance MODULE-COMPLIANCE 793 STATUS current 794 DESCRIPTION 795 "The compliance statement for SNMP engines that support 796 the SNMP-TRANSPORT-SM-MIB" 797 MODULE 798 MANDATORY-GROUPS { tsmGroup } 799 ::= { tsmCompliances 1 } 801 END 803 8. Security Considerations 805 This document describes a Security Model that permits SNMP to utilize 806 security services provided through an SNMP Transport Model. The 807 Transport Security Model relies on Transport Models for mutual 808 authentication, binding of keys, confidentiality and integrity. The 809 security threats and how those threats are mitigated should be 810 covered in detail in the specification of the Transport Model and the 811 underlying secure transport. 813 Transport Security Model relies on a Transport Model to provide an 814 authenticated principal for mapping to securityName, and an assertion 815 for mapping to securityLevel. 817 The Transport Security Model is called a Security Model to be 818 compatible with the RFC3411 architecture. However, this Security 819 Model provides no security itself. It SHOULD always be used with a 820 Transport Model that provides security, but this is a run-time 821 decision of the operator or management application, or a 822 configuration decision of an operator. 824 8.1. MIB module security 826 There are no management objects defined in this MIB module that have 827 a MAX-ACCESS clause of read-write and/or read-create. So, if this 828 MIB module is implemented correctly, then there is no risk that an 829 intruder can alter or create any management objects of this MIB 830 module via direct SNMP SET operations. 832 Some of the readable objects in this MIB module (i.e., objects with a 833 MAX-ACCESS other than not-accessible) may be considered sensitive or 834 vulnerable in some network environments. It is thus important to 835 control even GET and/or NOTIFY access to these objects and possibly 836 to even encrypt the values of these objects when sending them over 837 the network via SNMP. These are the tables and objects and their 838 sensitivity/vulnerability: 839 o tsmInvalidCache and tsmInadequateSecurity may make it easier for 840 an attacker to detect vulnerabilities. 842 SNMP versions prior to SNMPv3 did not include adequate security. 843 Even if the network itself is secure (for example by using IPsec), 844 even then, there is no control as to who on the secure network is 845 allowed to access and GET/SET (read/change/create/delete) the objects 846 in this MIB module. 848 It is RECOMMENDED that implementers consider the security features as 849 provided by the SNMPv3 framework (see [RFC3410] section 8), including 850 full support for the USM and Transport Security Model cryptographic 851 mechanisms (for authentication and privacy). 853 Further, deployment of SNMP versions prior to SNMPv3 is NOT 854 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 855 enable cryptographic security. It is then a customer/operator 856 responsibility to ensure that the SNMP entity giving access to an 857 instance of this MIB module is properly configured to give access to 858 the objects only to those principals (users) that have legitimate 859 rights to indeed GET or SET (change/create/delete) them. 861 9. IANA Considerations 863 IANA is requested to assign: 864 1. an SMI number under snmpModules, for the MIB module in this 865 document, 866 2. a value, preferably 4, to identify the Transport Security Model, 867 in the Security Models registry at 868 http://www.iana.org/assignments/snmp-number-spaces. This should 869 result in the following table of values: 870 Value Description References 871 ----- ----------- ---------- 872 0 reserved for 'any' [RFC2571, RFC3411] 873 1 reserved for SNMPv1 [RFC2571, RFC3411] 874 2 reserved for SNMPv2c [RFC2571, RFC3411] 875 3 User-Based Security Model (USM) [RFC2571, RFC3411] 876 YY Transport Security Model (TSM) [RFCXXXX] 878 -- NOTE to RFC editor: replace XXXX with actual RFC number 879 -- for this document and remove this note 880 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 881 throughout this document and remove this note. 883 10. References 885 10.1. Normative References 887 [RFC2119] Bradner, S., "Key words for use in RFCs to 888 Indicate Requirement Levels", BCP 14, RFC 2119, 889 March 1997. 891 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 892 Schoenwaelder, Ed., "Structure of Management 893 Information Version 2 (SMIv2)", STD 58, 894 RFC 2578, April 1999. 896 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 897 Schoenwaelder, Ed., "Textual Conventions for 898 SMIv2", STD 58, RFC 2579, April 1999. 900 [RFC2580] McCloghrie, K., Perkins, D., and J. 901 Schoenwaelder, "Conformance Statements for 902 SMIv2", STD 58, RFC 2580, April 1999. 904 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 905 Architecture for Describing Simple Network 906 Management Protocol (SNMP) Management 907 Frameworks", STD 62, RFC 3411, December 2002. 909 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 910 Wijnen, "Message Processing and Dispatching for 911 the Simple Network Management Protocol (SNMP)", 912 STD 62, RFC 3412, December 2002. 914 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 915 Network Management Protocol (SNMP) 916 Applications", STD 62, RFC 3413, December 2002. 918 [RFC3418] Presuhn, R., "Management Information Base (MIB) 919 for the Simple Network Management Protocol 920 (SNMP)", STD 62, RFC 3418, December 2002. 922 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 923 Subsystem for the Simple Network Management 924 Protocol (SNMP)", draft-ietf-isms-tmsm-06 (work 925 in progress), February 2007. 927 10.2. Informative References 929 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 930 Stewart, "Introduction and Applicability 931 Statements for Internet-Standard Management 932 Framework", RFC 3410, December 2002. 934 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 935 Security Model (USM) for version 3 of the 936 Simple Network Management Protocol (SNMPv3)", 937 STD 62, RFC 3414, December 2002. 939 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 940 Wijnen, "Coexistence between Version 1, Version 941 2, and Version 3 of the Internet-standard 942 Network Management Framework", BCP 74, 943 RFC 3584, August 2003. 945 Appendix A. Notification Tables Configuration 947 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 948 configure notification originators with the destinations to which 949 notifications should be sent. 951 Most of the configuration is security-model-independent and 952 transport-model-independent. 954 The values we will use in the examples for the five model-independent 955 security and transport parameters are: 956 transportDomain = snmpSSHDomain 957 transportAddress = 192.0.2.1:162 958 securityModel = Transport Security Model 959 securityName = sampleUser 960 securityLevel = authPriv 962 The following example will configure the Notification Originator to 963 send informs to a Notification Receiver at host 192.0.2.1 port 162 964 using the securityName "sampleUser". The columns marked with a "*" 965 are the items that are Security Model or Transport Model specific. 967 The configuration for the "sampleUser" settings in the SNMP-VIEW- 968 BASED-ACM-MIB objects are not shown here for brevity. First we 969 configure which type of notification should be sent for this taglist 970 (toCRTag). In this example, we choose to send an Inform. 971 snmpNotifyTable row: 972 snmpNotifyName CRNotif 973 snmpNotifyTag toCRTag 974 snmpNotifyType inform 975 snmpNotifyStorageType nonVolatile 976 snmpNotifyColumnStatus createAndGo 978 Then we configure a transport address to which notifications 979 associated with this taglist should be sent, and we specify which 980 snmpTargetParamsEntry should be used (toCR) when sending to this 981 transport address. 982 snmpTargetAddrTable row: 983 snmpTargetAddrName toCRAddr 984 * snmpTargetAddrTDomain snmpSSHDomain 985 snmpTargetAddrTAddress 192.0.2.1:162 986 snmpTargetAddrTimeout 1500 987 snmpTargetAddrRetryCount 3 988 snmpTargetAddrTagList toCRTag 989 snmpTargetAddrParams toCR (must match below) 990 snmpTargetAddrStorageType nonVolatile 991 snmpTargetAddrColumnStatus createAndGo 993 Then we configure which principal at the host should receive the 994 notifications associated with this taglist. Here we choose 995 "sampleUser", who uses the Transport Security Model. 996 snmpTargetParamsTable row: 997 snmpTargetParamsName toCR 998 snmpTargetParamsMPModel SNMPv3 999 * snmpTargetParamsSecurityModel TransportSecurityModel 1000 * snmpTargetParamsSecurityName "sampleUser" 1001 snmpTargetParamsSecurityLevel authPriv 1002 snmpTargetParamsStorageType nonVolatile 1003 snmpTargetParamsRowStatus createAndGo 1005 A.1. Transport Security Model Processing 1007 The Transport Security Model is called using the generateRequestMsg() 1008 ASI, with the following parameters (* are from the above tables): 1010 statusInformation = -- success or errorIndication 1011 generateRequestMsg( 1012 IN messageProcessingModel -- *snmpTargetParamsMPModel 1013 IN globalData -- message header, admin data 1014 IN maxMessageSize -- of the sending SNMP entity 1015 IN transportDomain -- *snmpTargetAddrTDomain 1016 IN transportAddress -- *snmpTargetAddrTAddress 1017 IN securityModel -- *snmpTargetParamsSecurityModel 1018 IN securityEngineID -- immaterial; TSM will ignore. 1019 IN securityName -- *snmpTargetParamsSecurityName 1020 IN securityLevel -- *snmpTargetParamsSecurityLevel 1021 IN scopedPDU -- message (plaintext) payload 1022 OUT securityParameters -- filled in by Security Module 1023 OUT wholeMsg -- complete generated message 1024 OUT wholeMsgLength -- length of generated message 1025 OUT tmStateReference -- reference to transport info 1026 ) 1028 The Transport Security Model will determine the Transport Model based 1029 on the snmpTargetAddrTDomain. The selected Transport Model will 1030 select the appropriate transport "session" using the 1031 snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and 1032 snmpTargetParamsSecurityLevel. 1034 Appendix B. Change Log 1036 From -02- to -03- 1037 Editorial changes suggested by Juergen Schoenwaelder 1038 Capitalized Transport Models, Security Models, and Message 1039 Processing Models, to be consistent with RFC341x conventions. 1040 Eliminated some text that duplicated RFC3412, especially in 1041 Elements of Procedure. 1042 Changed the encoding of msgSecurityParameters 1043 Marked the (NEW) fields added to existing ASIs 1044 Modified text intro discussing relationships to other MIB modules. 1046 From -01- to -02- 1048 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1049 waiting for assignment 1050 cleaned up elements of procedure [todo]s 1051 use the same errorIndication as USM for unsupportedSecurityLevel 1052 fixed syntax of tsmInadequateSecurity counter 1053 changed the "can and will use" the same security parameters to 1054 "can use", to allow responses that have different security 1055 parameters than the request. 1056 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1057 cleaned up "MIB Modules Required for IMPORTS" 1059 From -00- to -01- 1061 made the Transport Model not know anything about the Security 1062 Model. 1063 modified the elements of procedure sections, given the 1064 implications of this change. 1065 simplified elements of procedure, removing most info specified in 1066 architecture/subsystem definitions. 1067 rethought the coexistence section 1068 noted the implications of the Transport Security Model on 1069 isAccessAllowed() 1070 modified all text related to the LCD. 1071 removed most of the MIB (now the TSM has no configuration 1072 parameters). 1073 added counters needed to support elements of procedure 1074 renamed MIB module, and registered under snmpModules 1075 updated IANA and Security Considerations 1076 updated references. 1077 modified the notification configurations. 1079 From SSHSM-04- to Transport-security-model-00 1081 added tsmUserTable 1082 updated Appendix - Notification Tables Configuration 1083 remove open/closed issue appendices 1084 changed tmSessionReference to tmStateReference 1086 Author's Address 1088 David Harrington 1089 Huawei Technologies (USA) 1090 1700 Alma Dr. Suite 100 1091 Plano, TX 75075 1092 USA 1094 Phone: +1 603 436 8634 1095 EMail: dharrington@huawei.com 1097 Full Copyright Statement 1099 Copyright (C) The IETF Trust (2007). 1101 This document is subject to the rights, licenses and restrictions 1102 contained in BCP 78, and except as set forth therein, the authors 1103 retain all their rights. 1105 This document and the information contained herein are provided on an 1106 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1107 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1108 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1109 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1110 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1111 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1113 Intellectual Property 1115 The IETF takes no position regarding the validity or scope of any 1116 Intellectual Property Rights or other rights that might be claimed to 1117 pertain to the implementation or use of the technology described in 1118 this document or the extent to which any license under such rights 1119 might or might not be available; nor does it represent that it has 1120 made any independent effort to identify any such rights. Information 1121 on the procedures with respect to rights in RFC documents can be 1122 found in BCP 78 and BCP 79. 1124 Copies of IPR disclosures made to the IETF Secretariat and any 1125 assurances of licenses to be made available, or the result of an 1126 attempt made to obtain a general license or permission for the use of 1127 such proprietary rights by implementers or users of this 1128 specification can be obtained from the IETF on-line IPR repository at 1129 http://www.ietf.org/ipr. 1131 The IETF invites any interested party to bring to its attention any 1132 copyrights, patents or patent applications, or other proprietary 1133 rights that may cover technology that may be required to implement 1134 this standard. Please address the information to the IETF at 1135 ietf-ipr@ietf.org. 1137 Acknowledgement 1139 Funding for the RFC Editor function is provided by the IETF 1140 Administrative Support Activity (IASA).