idnits 2.17.1 draft-ietf-isms-transport-security-model-05.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 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1146. 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 (July 7, 2007) is 6131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 861, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-08 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' -- Obsolete informational reference (is this intentional?): RFC 2571 (Obsoleted by RFC 3411) -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 11 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 July 7, 2007 5 Expires: January 8, 2008 7 Transport Security Model for SNMP 8 draft-ietf-isms-transport-security-model-05 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 January 8, 2008. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 18 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 Some terminology used in this document was defined as part of the 130 IETF SNMPv3 Standard (STD62) or existed in normal English before the 131 informational 'Internet Security Glossary' [RFC2828] was published. 132 For consistency with related specifications, where necessary, this 133 document favors terminology consistent with STD62 rather than with 134 the Internet Security Glossary. This is consistent with the IESG 135 decision to not require the SNMPv3 terminology be modified to match 136 RFC2828 when SNMPv3 was advanced to Full Standard. 138 Authentication in this document typically refers to the English 139 meaning of "serving to prove the authenticity of" the message, not 140 data source authentication or peer identity authentication. 142 The terms "manager" and "agent" are not used in this document, 143 because in the RFC 3411 architecture, all SNMP entities have the 144 capability of acting as either manager or agent or both depending on 145 the SNMP applications included in the engine. Where distinction is 146 required, the application names of Command Generator, Command 147 Responder, Notification Originator, Notification Receiver, and Proxy 148 Forwarder are used. See "SNMP Applications" [RFC3413] for further 149 information. 151 While security protocols frequently refer to a user, the terminology 152 used in RFC3411 [RFC3411] and in this memo is "principal". A 153 principal is the "who" on whose behalf services are provided or 154 processing takes place. A principal can be, among other things, an 155 individual acting in a particular role; a set of individuals, with 156 each acting in a particular role; an application or a set of 157 applications, or a combination of these within an administrative 158 domain. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 1.3. Modularity 166 The reader is expected to have read and understood the description of 167 the SNMP architecture, as defined in [RFC3411], and the architecture 168 extension specified in "Transport Subsystem for the Simple Network 169 Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of 170 external "lower layer transport" protocols to provide message 171 security, tied into the SNMP architecture through the Transport 172 Subsystem. The Transport Security Model is designed to work with 173 such lower-layer secure Transport Models. 175 In keeping with the RFC 3411 design decisions to use self-contained 176 documents, this memo includes the elements of procedure plus 177 associated MIB objects which are needed for processing the Transport 178 Security Model for SNMP. These MIB objects SHOULD not be referenced 179 in other documents. This allows the Transport Security Model to be 180 designed and documented as independent and self-contained, having no 181 direct impact on other modules, and allowing this module to be 182 upgraded and supplemented as the need arises, and to move along the 183 standards track on different time-lines from other modules. 185 This modularity of specification is not meant to be interpreted as 186 imposing any specific requirements on implementation. 188 1.4. Motivation 190 This memo describes a Security Model to make use of Transport Models 191 that use lower layer secure transports and existing and commonly 192 deployed security infrastructures. This Security Model is designed 193 to meet the security and operational needs of network administrators, 194 maximize usability in operational environments to achieve high 195 deployment success and at the same time minimize implementation and 196 deployment costs to minimize the time until deployment is possible. 198 1.5. Constraints 200 The design of this SNMP Security Model is also influenced by the 201 following constraints: 202 1. In times of network stress, the security protocol and its 203 underlying security mechanisms SHOULD NOT depend solely upon the 204 ready availability of other network services (e.g., Network Time 205 Protocol (NTP) or Authentication, Authorization, and Accounting 206 (AAA) protocols). 207 2. 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 3. It may not be possible for the Security Model to determine when 211 the network is under stress. 212 4. A Security Model should require no changes to the SNMP 213 architecture. 214 5. A Security Model should require no changes to the underlying 215 security protocol. 217 2. How the 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 A cache, referenced by tmStateReference, is used to pass information 224 between the Transport Security Model and a Transport Model, and vice 225 versa. If the Transport Security Model is used with an insecure 226 Transport Model, then the cache is unlikely to be populated with 227 security parameters, which will cause the Transport Security Model to 228 return an error (see section 5.2) If another Security Model (eg 229 Community-based Security Model) is used with a secure Transport 230 Model, then the cache may be populated but the other Security Model 231 may be unaware of the cache and ignore its contents (eg deriving the 232 securityName from the Community name in the message instead of 233 deriving it from the cache). When the Transport Security Model is 234 used with a secure Transport Model, the information in the cache is 235 used by the Transport Security Model to translate between the 236 security model-independent securityName and any identity used by the 237 secure transport; and to record the tmSecurityLevel provided for the 238 message by the transport (a level of security which may exceed the 239 securityLevel requested for the message by the application). 241 The Transport Model of an SNMP engine will perform the translation 242 between transport-specific security parameters and the SNMP-specific, 243 model-independent parameters securityName and securityLevel. To 244 maintain the RFC3411 modularity, the Transport Model does not know 245 which securityModel will be used for an incoming message; the Message 246 Processing Model will determine the securityModel to be used, in a 247 Message Processing Model dependent manner. 249 2.1. Security Capabilities of this Model 251 2.1.1. Threats 253 The Transport Security Model, when used with suitable secure 254 Transport Models, provides protection against the threats identified 255 by the RFC 3411 architecture [RFC3411]. 257 Which threats are addressed depends on the Transport Model. The 258 Transport Security Model does not address any threats itself, but 259 delegates that responsibility to a secure Transport Model. 261 The Transport Security Model is called a Security Model to be 262 compatible with the RFC3411 architecture. However, this Security 263 Model does not provide security mechanisms such as authentication and 264 encryption itself, so it SHOULD always be used with a Transport Model 265 that provides appropriate security. 267 2.1.2. Security Levels 269 The RFC 3411 architecture recognizes three levels of security: 270 - without authentication and without privacy (noAuthNoPriv) 271 - with authentication but without privacy (authNoPriv) 272 - with authentication and with privacy (authPriv) 274 The model-independent securityLevel parameter is used to request 275 specific levels of security for outgoing messages, and to assert that 276 specific levels of security were applied during the transport and 277 processing of incoming messages. 279 The transport layer algorithms used to provide security SHOULD NOT be 280 exposed to the Transport Security Model, as the Transport Security 281 Model has no mechanisms by which it can test whether an assertion 282 made by a Transport Model is accurate. 284 The Transport Security Model trusts that the underlying secure 285 transport connection has been properly configured to support security 286 characteristics at least as strong as requested in securityLevel. 288 2.2. No Sessions 290 The Transport Security Model will associate state regarding each 291 message and each known remote engine with a single combination of 292 transportDomain, transportAddress, securityName, securityModel, and 293 securityLevel. 295 Some Transport Models will utilize sessions to maintain long-lived 296 state; others will use stateless transport. For reasons of module 297 independence, the Transport Security Model will make no assumptions 298 about there being a session of any kind. Each message may be totally 299 independent of other messages. Any binding of multiples messages 300 into a session is specific to the Transport Model. There may be 301 circumstances where having an SNMP-specific session provided by a 302 Security Model is useful; such functionality is left to future 303 Security Models. 305 2.3. Coexistence 307 There are two primary factors which determine whether Security Models 308 can coexist. First, there must be a mechanism to select different 309 Security Models at run-time. Second, the processing of one Security 310 Model should not impact the processing of another Security Model. 312 In the RFC3411 architecture, a Message Processing Model determines 313 which Security Model should be called. As of this writing, IANA has 314 registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ 315 SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, 316 SNMPv2c, and the User-based Security Model). 318 The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 319 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 320 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 321 message. Since there is no field in the message format that permits 322 specifying a Security Model, RFC3584 message processing does not 323 permit the selection of Security Models other than SNMPv1 or SNMPv2. 324 Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or 325 SNMPv2 Message Processing Models **as defined in RFC3584** cannot use 326 the Transport Security Model. (This does not mean an SNMPv1 or 327 SNMPv2 message cannot use a secure transport model, only that the 328 RFC3584 MPM will not invoke this security model.) 330 The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact 331 for which there is no existing IETF specification. 333 The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts 334 the securityModel from the msgSecurityModel field of an incoming 335 SNMPv3Message. When the extracted value of msgSecurityModel is 336 transportSecurityModel(YY), security processing is directed to the 337 Transport Security Model. For an outgoing message to be secured 338 using the Transport Security Model, msgSecurityModel should be set to 339 transportSecurityModel(YY). 341 The Transport Security Model uses its own MIB module for processing 342 to maintain independence from other Security Models. This allows the 343 Transport Security Model to coexist with other Security Models, such 344 as the User-based Security Model. 346 Note that the Transport Security Model may work with multiple 347 Transport Models, but the isAccessAllowed() primitive only accepts a 348 value for the Security Model, not for Transport Models. As a result, 349 it is not possible to have different access control rules for 350 different Transport Models that use the Transport Security Model. 352 2.4. Security Parameter Passing 354 For outgoing messages, Transport Security Model takes input provided 355 by the SNMP application, converts that information into suitable 356 transport and security parameters in a cache referenced by 357 tmStateReference. The wholeMsg and the tmStateReference are passed 358 to the appropriate Transport Model through a series of APIs, as 359 described in "Transport Subsystem for the Simple Network Management 360 Protocol" [I-D.ietf-isms-tmsm]. 362 For incoming messages, the Transport Model accepts messages from the 363 lower layer transport, and records the transport-related information 364 and security-related information, including a securityName that 365 represents the authenticated identity, and a securityLevel that 366 represents the security features provided during transport, in a 367 cache referenced by tmStateReference. The wholeMsg and the 368 tmStateReference are passed to the appropriate Security Model through 369 a series of APIs, as described in "Transport Subsystem for the Simple 370 Network Management Protocol" [I-D.ietf-isms-tmsm]. 372 2.5. Notifications and Proxy 374 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 375 management targets, including transportDomain, transportAddress, 376 securityName, securityModel, and securityLevel parameters, for 377 applications such as notifications and proxy. For the Transport 378 Security Model, transport type and address are configured in the 379 snmpTargetAddrTable, and the securityModel, securityName, and 380 securityLevel parameters are configured in the snmpTargetParamsTable. 382 The default approach is for an administrator to statically configure 383 this information to identify the targets authorized to receive 384 notifications or perform proxy. 386 3. Cached Information and References 388 The RFC3411 architecture uses caches to store dynamic model-specific 389 information, and uses references in the ASIs to indicate in a model- 390 independent manner which cached information must flow between 391 subsystems. 393 There are two levels of state that may need to be maintained: the 394 security state in a request-response pair, and potentially long-term 395 state relating to transport and security. This document describes 396 caches, and differentiates the tmStateReference from the 397 securityStateReference, but how this is represented internally is an 398 implementation decision. 400 As a general rule, if state information is available when a message 401 being processed gets discarded, the state related to that message 402 should also be discarded, and if state information is available when 403 a relationship between engines is severed, such as the closing of a 404 transport session, the state information for that relationship might 405 also be discarded. 407 3.1. securityStateReference 409 The securityStateReference parameter is defined in RFC3411. A sample 410 model-specific cache can be found in RFC3414 [RFC3414]. 412 3.2. tmStateReference 414 For each transport session, information about the message security is 415 stored in a cache to pass model- and mechanism-specific parameters. 416 The state referenced by tmStateReference may be saved across multiple 417 messages, in a Local Configuration Datastore (LCD), as compared to 418 securityStateReference which is usually only saved for the life of a 419 request-response pair of messages. 421 For security reasons, if a secure transport session is closed between 422 the time a request message is received and the corresponding response 423 message is sent, then the response message MUST be discarded, even if 424 a new session has been established. Each Security Model SHOULD pass 425 a tmSameSession parameter in the tmStateReference cache for outgoing 426 messages to indicate whether the same session must be used for the 427 outgoing message as was used for the corresponding incoming message. 429 The format of the cache and the LCD are implementation-specific. 431 4. Processing an Outgoing Message 433 An error indication may return an OID and value for an incremented 434 counter and a value for securityLevel, and values for contextEngineID 435 and contextName for the counter, and the securityStateReference if 436 the information is available at the point where the error is 437 detected. 439 4.1. Security Processing for an Outgoing Message 441 This section describes the procedure followed by the Transport 442 Security Model. 444 The parameters needed for generating a message are supplied to the 445 Security Model by the Message Processing Model via the 446 generateRequestMsg() or the generateResponseMsg() ASI. The Transport 447 Subsystem architectural extension has added the transportDomain, 448 transportAddress, and tmStateReference parameters to the original 449 RFC3411 ASIs. 451 statusInformation = -- success or errorIndication 452 generateRequestMsg( 453 IN messageProcessingModel -- typically, SNMP version 454 IN globalData -- message header, admin data 455 IN maxMessageSize -- of the sending SNMP entity 456 IN transportDomain -- (NEW) specified by application 457 IN transportAddress -- (NEW) specified by application 458 IN securityModel -- for the outgoing message 459 IN securityEngineID -- authoritative SNMP entity 460 IN securityName -- on behalf of this principal 461 IN securityLevel -- Level of Security requested 462 IN scopedPDU -- message (plaintext) payload 463 OUT securityParameters -- filled in by Security Module 464 OUT wholeMsg -- complete generated message 465 OUT wholeMsgLength -- length of generated message 466 OUT tmStateReference -- (NEW) transport info 467 ) 469 statusInformation = -- success or errorIndication 470 generateResponseMsg( 471 IN messageProcessingModel -- typically, SNMP version 472 IN globalData -- message header, admin data 473 IN maxMessageSize -- of the sending SNMP entity 474 IN transportDomain -- (NEW) specified by application 475 IN transportAddress -- (NEW) specified by application 476 IN securityModel -- for the outgoing message 477 IN securityEngineID -- authoritative SNMP entity 478 IN securityName -- on behalf of this principal 479 IN securityLevel -- Level of Security requested 480 IN scopedPDU -- message (plaintext) payload 481 IN securityStateReference -- reference to security state 482 -- information from original 483 -- request 484 OUT securityParameters -- filled in by Security Module 485 OUT wholeMsg -- complete generated message 486 OUT wholeMsgLength -- length of generated message 487 OUT tmStateReference -- (NEW) transport info 488 ) 490 4.2. securityLevel 492 For an incoming message, the Message Processing Model specifies the 493 requested securityLevel to the Security Model. When the Transport 494 Security Model processes an incoming message, if the securityLevel 495 reported by the Transport Model in the cache is less than the 496 securityLevel requested via the processIncomingMsg ASI, it discards 497 the message, and notifies the Message Processing Model. 499 4.3. Elements of Procedure for Outgoing Messages 501 1) If there is a securityStateReference, then this is a response 502 message. Extract transportDomain, transportAddress, securityName, 503 securityLevel, securityModel, and tmStateReference from the cache. 504 The cachedSecurityData for this message can now be discarded. Set 505 the tmSameSession parameter in the tmStateReference cache to true. 507 2) If there is no securityStateReference, then find or create an 508 entry in a Local Configuration Datastore containing the provided 509 transportDomain, transportAddress, securityName, securityLevel, and 510 securityModel, create a tmStateReference to reference the entry. 512 3) Fill in the securityParameters with a zero-length OCTET STRING 513 ('0400'). 515 4) Combine the message parts into a wholeMsg and calculate 516 wholeMsgLength. 518 5) The wholeMsg, wholeMsgLength, securityParameters and 519 tmStateReference are returned to the calling Message Processing Model 520 with the statusInformation set to success. 522 5. Processing an Incoming SNMP Message 524 An error indication may return an OID and value for an incremented 525 counter and a value for securityLevel, and values for contextEngineID 526 and contextName for the counter, and the securityStateReference if 527 the information is available at the point where the error is 528 detected. 530 5.1. Security Processing for an Incoming Message 532 This section describes the procedure followed by the Transport 533 Security Model whenever it receives an incoming message from a 534 Message Processing Model. The abstract service primitive from a 535 Message Processing Model to the Security Subsystem for a received 536 message is: 538 statusInformation = -- errorIndication or success 539 -- error counter OID/value if error 540 processIncomingMsg( 541 IN messageProcessingModel -- typically, SNMP version 542 IN maxMessageSize -- from the received message 543 IN securityParameters -- from the received message 544 IN securityModel -- from the received message 545 IN securityLevel -- from the received message 546 IN wholeMsg -- as received on the wire 547 IN wholeMsgLength -- length as received on the wire 548 IN tmStateReference -- (NEW) from the Transport Model 549 OUT securityEngineID -- authoritative SNMP entity 550 OUT securityName -- identification of the principal 551 OUT scopedPDU, -- message (plaintext) payload 552 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 553 OUT securityStateReference -- reference to security state 554 ) -- information, needed for response 556 5.2. Elements of Procedure for Incoming Messages 558 1) Set the securityEngineID to the local snmpEngineID. 560 2) 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 3) Extract the value of securityName from the cache referenced by 566 tmStateReference. 568 4) The scopedPDU component is extracted from the wholeMsg. 570 5) The maxSizeResponseScopedPDU is calculated. This is the maximum 571 size allowed for a scopedPDU for a possible Response message. 573 6) 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 7) 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 8)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 9) 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 "200707050000Z" 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 Jacobs 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 "200707050000Z" 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 } 707 -- RFC Ed.: replace xxxx with IANA-assigned number and 708 -- remove this note 710 -- ---------------------------------------------------------- -- 711 -- subtrees in the SNMP-TRANSPORT-SM-MIB 712 -- ---------------------------------------------------------- -- 714 tsmNotifications OBJECT IDENTIFIER ::= { tsmMIB 0 } 715 tsmMIBObjects OBJECT IDENTIFIER ::= { tsmMIB 1 } 716 tsmConformance OBJECT IDENTIFIER ::= { tsmMIB 2 } 718 -- ------------------------------------------------------------- 719 -- Objects 720 -- ------------------------------------------------------------- 722 -- Statistics for the Transport Security Model 724 tsmStats OBJECT IDENTIFIER ::= { tsmMIBObjects 1 } 726 tsmInvalidCache OBJECT-TYPE 727 SYNTAX Counter32 728 MAX-ACCESS read-only 729 STATUS current 730 DESCRIPTION "The number of messages dropped because the 731 tmStateReference referred to an invalid cache. 733 This value is not persistent across reboots. 734 " 735 ::= { tsmStats 1 } 737 tsmInadequateSecurity OBJECT-TYPE 738 SYNTAX Counter32 739 MAX-ACCESS read-only 740 STATUS current 741 DESCRIPTION "The number of incoming messages dropped because 742 the actual securityLevel provided was less than 743 the requested securityLevel. 745 This value is not persistent across reboots. 746 " 747 ::= { tsmStats 2 } 749 -- ------------------------------------------------------------- 750 -- tsmMIB - Conformance Information 751 -- ------------------------------------------------------------- 753 tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } 754 tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } 756 -- ------------------------------------------------------------- 757 -- Units of conformance 758 -- ------------------------------------------------------------- 759 tsmGroup OBJECT-GROUP 760 OBJECTS { 761 tsmInvalidCache, 762 tsmInadequateSecurity 763 } 764 STATUS current 765 DESCRIPTION "A collection of objects for maintaining 766 information of an SNMP engine which implements 767 the SNMP Transport Security Model. 768 " 770 ::= { tsmGroups 2 } 772 -- ------------------------------------------------------------- 773 -- Compliance statements 774 -- ------------------------------------------------------------- 776 tsmCompliance MODULE-COMPLIANCE 777 STATUS current 778 DESCRIPTION 779 "The compliance statement for SNMP engines that support 780 the SNMP-TRANSPORT-SM-MIB" 781 MODULE 782 MANDATORY-GROUPS { tsmGroup } 783 ::= { tsmCompliances 1 } 785 END 787 8. Security Considerations 789 This document describes a Security Model that permits SNMP to utilize 790 security services provided through an SNMP Transport Model. The 791 Transport Security Model relies on Transport Models for mutual 792 authentication, binding of keys, confidentiality and integrity. The 793 security threats and how those threats are mitigated should be 794 covered in detail in the specification of the Transport Model and the 795 underlying secure transport. 797 Transport Security Model relies on a Transport Model to provide an 798 authenticated principal for mapping to securityName, and an assertion 799 for mapping to securityLevel. 801 The Transport Security Model is called a Security Model to be 802 compatible with the RFC3411 architecture. However, this Security 803 Model provides no security itself. It SHOULD always be used with a 804 Transport Model that provides security, but this is a run-time 805 decision of the operator or management application, or a 806 configuration decision of an operator. 808 8.1. MIB module security 810 There are no management objects defined in this MIB module that have 811 a MAX-ACCESS clause of read-write and/or read-create. So, if this 812 MIB module is implemented correctly, then there is no risk that an 813 intruder can alter or create any management objects of this MIB 814 module via direct SNMP SET operations. 816 Some of the readable objects in this MIB module (i.e., objects with a 817 MAX-ACCESS other than not-accessible) may be considered sensitive or 818 vulnerable in some network environments. It is thus important to 819 control even GET and/or NOTIFY access to these objects and possibly 820 to even encrypt the values of these objects when sending them over 821 the network via SNMP. These are the tables and objects and their 822 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, 851 2. a value, preferably 4, to identify the Transport Security Model, 852 in the Security Models registry at 853 http://www.iana.org/assignments/snmp-number-spaces. This should 854 result in the following table of values: 855 Value Description References 856 ----- ----------- ---------- 857 0 reserved for 'any' [RFC2571, RFC3411] 858 1 reserved for SNMPv1 [RFC2571, RFC3411] 859 2 reserved for SNMPv2c [RFC2571, RFC3411] 860 3 User-Based Security Model (USM) [RFC2571, RFC3411] 861 YY Transport Security Model (TSM) [RFCXXXX] 863 -- NOTE to RFC editor: replace XXXX with actual RFC number 864 -- for this document and remove this note 865 -- NOTE to RFC editor: replace YY with actual IANA-assigned number, 866 throughout this document and remove this note. 868 10. References 870 10.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to 873 Indicate Requirement Levels", BCP 14, RFC 2119, 874 March 1997. 876 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 877 Schoenwaelder, Ed., "Structure of Management 878 Information Version 2 (SMIv2)", STD 58, 879 RFC 2578, April 1999. 881 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 882 Schoenwaelder, Ed., "Textual Conventions for 883 SMIv2", STD 58, RFC 2579, April 1999. 885 [RFC2580] McCloghrie, K., Perkins, D., and J. 886 Schoenwaelder, "Conformance Statements for 887 SMIv2", STD 58, RFC 2580, April 1999. 889 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 890 Architecture for Describing Simple Network 891 Management Protocol (SNMP) Management 892 Frameworks", STD 62, RFC 3411, December 2002. 894 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. 895 Wijnen, "Message Processing and Dispatching for 896 the Simple Network Management Protocol (SNMP)", 897 STD 62, RFC 3412, December 2002. 899 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple 900 Network Management Protocol (SNMP) 901 Applications", STD 62, RFC 3413, December 2002. 903 [RFC3418] Presuhn, R., "Management Information Base (MIB) 904 for the Simple Network Management Protocol 905 (SNMP)", STD 62, RFC 3418, December 2002. 907 [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport 908 Subsystem for the Simple Network Management 909 Protocol (SNMP)", draft-ietf-isms-tmsm-08 (work 910 in progress), May 2007. 912 10.2. Informative References 914 [RFC2571] Wijnen, B., Harrington, D., and R. Presuhn, "An 915 Architecture for Describing SNMP Management 916 Frameworks", RFC 2571, April 1999. 918 [RFC2828] Shirey, R., "Internet Security Glossary", 919 RFC 2828, May 2000. 921 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 922 Stewart, "Introduction and Applicability 923 Statements for Internet-Standard Management 924 Framework", RFC 3410, December 2002. 926 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based 927 Security Model (USM) for version 3 of the 928 Simple Network Management Protocol (SNMPv3)", 929 STD 62, RFC 3414, December 2002. 931 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. 932 Wijnen, "Coexistence between Version 1, Version 933 2, and Version 3 of the Internet-standard 934 Network Management Framework", BCP 74, 935 RFC 3584, August 2003. 937 Appendix A. Notification Tables Configuration 939 The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to 940 configure notification originators with the destinations to which 941 notifications should be sent. 943 Most of the configuration is security-model-independent and 944 transport-model-independent. 946 The values we will use in the examples for the five model-independent 947 security and transport parameters are: 948 transportDomain = snmpSSHDomain 949 transportAddress = 192.0.2.1:162 950 securityModel = Transport Security Model 951 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 -04- to -05- 1031 Removed check for empty securityParameters for incoming messages 1032 Added text about differences in terminology from RFC2828. 1034 From -03- to -04- 1035 Editorial changes requested by Tom Petch, to clarify behavior with 1036 SNMPv1/v2c 1037 Added early discussion of how TSM fits into the architecture to 1038 clarify behavior when RFC3584 security models are co-resident. 1039 Editorial changes requested by Bert Wijnen, to eliminate version- 1040 specific discussions. 1041 Removed sections on version-specific message formats. 1042 Removed discussion of SNMPv3 in Motivation section. 1043 Added discussion of request/response session matching. 1045 From -02- to -03- 1047 Editorial changes suggested by Juergen Schoenwaelder 1048 Capitalized Transport Models, Security Models, and Message 1049 Processing Models, to be consistent with RFC341x conventions. 1050 Eliminated some text that duplicated RFC3412, especially in 1051 Elements of Procedure. 1052 Changed the encoding of msgSecurityParameters 1053 Marked the (NEW) fields added to existing ASIs 1054 Modified text intro discussing relationships to other MIB modules. 1056 From -01- to -02- 1058 Changed transportSecurityModel(4) to transportSecurityModel(YY), 1059 waiting for assignment 1060 cleaned up elements of procedure [todo]s 1061 use the same errorIndication as USM for unsupportedSecurityLevel 1062 fixed syntax of tsmInadequateSecurity counter 1063 changed the "can and will use" the same security parameters to 1064 "can use", to allow responses that have different security 1065 parameters than the request. 1066 removed "Relationship to the SNMP-FRAMEWORK-MIB" 1067 cleaned up "MIB Modules Required for IMPORTS" 1069 From -00- to -01- 1071 made the Transport Model not know anything about the Security 1072 Model. 1073 modified the elements of procedure sections, given the 1074 implications of this change. 1075 simplified elements of procedure, removing most info specified in 1076 architecture/subsystem definitions. 1077 rethought the coexistence section 1078 noted the implications of the Transport Security Model on 1079 isAccessAllowed() 1080 modified all text related to the LCD. 1082 removed most of the MIB (now the TSM has no configuration 1083 parameters). 1084 added counters needed to support elements of procedure 1085 renamed MIB module, and registered under snmpModules 1086 updated IANA and Security Considerations 1087 updated references. 1088 modified the notification configurations. 1090 From SSHSM-04- to Transport-security-model-00 1092 added tsmUserTable 1093 updated Appendix - Notification Tables Configuration 1094 remove open/closed issue appendices 1095 changed tmSessionReference to tmStateReference 1097 Author's Address 1099 David Harrington 1100 Huawei Technologies (USA) 1101 1700 Alma Dr. Suite 100 1102 Plano, TX 75075 1103 USA 1105 Phone: +1 603 436 8634 1106 EMail: dharrington@huawei.com 1108 Full Copyright Statement 1110 Copyright (C) The IETF Trust (2007). 1112 This document is subject to the rights, licenses and restrictions 1113 contained in BCP 78, and except as set forth therein, the authors 1114 retain all their rights. 1116 This document and the information contained herein are provided on an 1117 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1118 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1119 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1120 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1121 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1122 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1124 Intellectual Property 1126 The IETF takes no position regarding the validity or scope of any 1127 Intellectual Property Rights or other rights that might be claimed to 1128 pertain to the implementation or use of the technology described in 1129 this document or the extent to which any license under such rights 1130 might or might not be available; nor does it represent that it has 1131 made any independent effort to identify any such rights. Information 1132 on the procedures with respect to rights in RFC documents can be 1133 found in BCP 78 and BCP 79. 1135 Copies of IPR disclosures made to the IETF Secretariat and any 1136 assurances of licenses to be made available, or the result of an 1137 attempt made to obtain a general license or permission for the use of 1138 such proprietary rights by implementers or users of this 1139 specification can be obtained from the IETF on-line IPR repository at 1140 http://www.ietf.org/ipr. 1142 The IETF invites any interested party to bring to its attention any 1143 copyrights, patents or patent applications, or other proprietary 1144 rights that may cover technology that may be required to implement 1145 this standard. Please address the information to the IETF at 1146 ietf-ipr@ietf.org. 1148 Acknowledgement 1150 Funding for the RFC Editor function is provided by the IETF 1151 Administrative Support Activity (IASA).