idnits 2.17.1 draft-ietf-isms-tmsm-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 draft header indicates that this document updates RFC3411, but the abstract doesn't seem to directly say this. It does mention RFC3411 though, so this could be OK. -- The draft header indicates that this document updates RFC3412, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3414, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3417, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 406 has weird spacing: '...patcher v ...' == 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 the creation date from RFC3411, updated by this document, for RFC5378 checks: 2001-02-27) (Using the creation date from RFC3417, updated by this document, for RFC5378 checks: 2000-01-10) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2009) is 5476 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: 'XXXX' is mentioned on line 1351, but not defined -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-isms-secshell-15 Summary: 1 error (**), 0 flaws (~~), 5 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 Updates: 3411,3412,3414,3417 J. Schoenwaelder 5 (if approved) Jacobs University Bremen 6 Intended status: Standards Track April 27, 2009 7 Expires: October 29, 2009 9 Transport Subsystem for the Simple Network Management Protocol (SNMP) 10 draft-ietf-isms-tmsm-17 12 Status of This Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on October 29, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document defines a Transport Subsystem, extending the Simple 59 Network Management Protocol (SNMP) architecture defined in RFC 3411. 60 This document defines a subsystem to contain Transport Models, 61 comparable to other subsystems in the RFC3411 architecture. As work 62 is being done to expand the transports to include secure transports 63 such as SSH and TLS, using a subsystem will enable consistent design 64 and modularity of such Transport Models. This document identifies 65 and describes some key aspects that need to be considered for any 66 Transport Model for SNMP. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. The Internet-Standard Management Framework . . . . . . . . 4 72 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.3. Where this Extension Fits . . . . . . . . . . . . . . . . 4 74 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8 76 3.1. Message Security Requirements . . . . . . . . . . . . . . 8 77 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8 78 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8 79 3.2.1. Architectural Modularity Requirements . . . . . . . . 9 80 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12 81 3.2.3. Security Parameter Passing Requirements . . . . . . . 13 82 3.2.4. Separation of Authentication and Authorization . . . . 13 83 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14 84 3.3.1. No SNMP Sessions . . . . . . . . . . . . . . . . . . . 14 85 3.3.2. Session Establishment Requirements . . . . . . . . . . 15 86 3.3.3. Session Maintenance Requirements . . . . . . . . . . . 16 87 3.3.4. Message security versus session security . . . . . . . 16 88 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17 89 5. Cached Information and References . . . . . . . . . . . . . . 17 90 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18 91 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18 92 5.2.1. Transport information . . . . . . . . . . . . . . . . 19 93 5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 20 94 5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20 95 5.2.4. Session Information . . . . . . . . . . . . . . . . . 21 96 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21 97 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 22 98 6.2. Changes to RFC3411 Outgoing ASIs . . . . . . . . . . . . . 23 99 6.2.1. Message Processing Subsystem Primitives . . . . . . . 23 100 6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 24 101 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 25 102 6.4. Changes to RFC3411 Incoming ASIs . . . . . . . . . . . . . 26 103 6.4.1. Message Processing Subsystem Primitive . . . . . . . . 26 104 6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 27 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 106 7.1. Coexistence, Security Parameters, and Access Control . . . 29 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 112 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 34 113 A.1. Define an Abstract Service Interface . . . . . . . . . . . 34 114 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 35 115 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 35 116 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 35 118 1. Introduction 120 This document defines a Transport Subsystem, extending the Simple 121 Network Management Protocol (SNMP) architecture defined in [RFC3411]. 122 This document identifies and describes some key aspects that need to 123 be considered for any Transport Model for SNMP. 125 1.1. The Internet-Standard Management Framework 127 For a detailed overview of the documents that describe the current 128 Internet-Standard Management Framework, please refer to section 7 of 129 RFC 3410 [RFC3410]. 131 1.2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 Non uppercased versions of the keywords should be read as in normal 138 English. They will usually, but not always, be used in a context 139 relating to compatibility with the RFC3411 architecture or the 140 subsystem defined here, but which might have no impact on on-the-wire 141 compatibility. These terms are used as guidance for designers of 142 proposed IETF models to make the designs compatible with RFC3411 143 subsystems and Abstract Service Interfaces (ASIs) (see section 3.2). 144 Implementers are free to implement differently. Some usages of these 145 lowercase terms are simply normal English usage. 147 For consistency with SNMP-related specifications, this document 148 favors terminology as defined in STD62 rather than favoring 149 terminology that is consistent with non-SNMP specifications that use 150 different variations of the same terminology. This is consistent 151 with the IESG decision to not require the SNMPv3 terminology be 152 modified to match the usage of other non-SNMP specifications when 153 SNMPv3 was advanced to Full Standard. 155 1.3. Where this Extension Fits 157 It is expected that readers of this document will have read RFC3410 158 and RFC3411, and have a general understanding of the functionality 159 defined in RFCs 3412-3418. 161 The "Transport Subsystem" is an additional component for the SNMP 162 Engine depicted in RFC3411, section 3.1. 164 The following diagram depicts its place in the RFC3411 architecture.: 166 +-------------------------------------------------------------------+ 167 | SNMP entity | 168 | | 169 | +-------------------------------------------------------------+ | 170 | | SNMP engine (identified by snmpEngineID) | | 171 | | | | 172 | | +------------+ | | 173 | | | Transport | | | 174 | | | Subsystem | | | 175 | | +------------+ | | 176 | | | | 177 | | +------------+ +------------+ +-----------+ +-----------+ | | 178 | | | Dispatcher | | Message | | Security | | Access | | | 179 | | | | | Processing | | Subsystem | | Control | | | 180 | | | | | Subsystem | | | | Subsystem | | | 181 | | +------------+ +------------+ +-----------+ +-----------+ | | 182 | +-------------------------------------------------------------+ | 183 | | 184 | +-------------------------------------------------------------+ | 185 | | Application(s) | | 186 | | | | 187 | | +-------------+ +--------------+ +--------------+ | | 188 | | | Command | | Notification | | Proxy | | | 189 | | | Generator | | Receiver | | Forwarder | | | 190 | | +-------------+ +--------------+ +--------------+ | | 191 | | | | 192 | | +-------------+ +--------------+ +--------------+ | | 193 | | | Command | | Notification | | Other | | | 194 | | | Responder | | Originator | | | | | 195 | | +-------------+ +--------------+ +--------------+ | | 196 | +-------------------------------------------------------------+ | 197 | | 198 +-------------------------------------------------------------------+ 200 The transport mappings defined in RFC3417 do not provide lower-layer 201 security functionality, and thus do not provide transport-specific 202 security parameters. This document updates RFC3411 and RFC3417 by 203 defining an architectural extension and modifying the ASIs that 204 transport mappings (hereafter called transport models) can use to 205 pass transport-specific security parameters to other subsystems, 206 including transport-specific security parameters that are translated 207 into the transport-independent securityName and securityLevel 208 parameters 210 The Transport Security Model [I-D.ietf-isms-transport-security-model] 211 and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize 212 the Transport Subsystem. The Transport Security Model is an 213 alternative to the existing SNMPv1 Security Model [RFC3584], the 214 SNMPv2c Security Model [RFC3584], and the User-based Security Model 215 [RFC3414]. The Secure Shell Transport Model is an alternative to 216 existing transport mappings as described in [RFC3417]. 218 2. Motivation 220 Just as there are multiple ways to secure one's home or business, in 221 a continuum of alternatives, there are multiple ways to secure a 222 network management protocol. Let's consider three general 223 approaches. 225 In the first approach, an individual could sit on his front porch 226 waiting for intruders. In the second approach, he could hire an 227 employee, schedule the employee, position the employee to guard what 228 he wants protected, hire a second guard to cover if the first gets 229 sick, and so on. In the third approach, he could hire a security 230 company, tell them what he wants protected, and leave the details to 231 them. Considerations of hiring and training employees, positioning 232 and scheduling the guards, arranging for cover, etc., are the 233 responsibility of the security company. The individual therefore 234 achieves the desired security, with significantly less effort on his 235 part except identifying requirements and verifying the quality of 236 service being provided. 238 The User-based Security Model (USM) as defined in [RFC3414] largely 239 uses the first approach - it provides its own security. It utilizes 240 existing mechanisms (e.g., SHA), but provides all the coordination. 241 USM provides for the authentication of a principal, message 242 encryption, data integrity checking, timeliness checking, etc. 244 USM was designed to be independent of other existing security 245 infrastructures. USM therefore requires a separate principal and key 246 management infrastructure. Operators have reported that deploying 247 another principal and key management infrastructure in order to use 248 SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use 249 external mechanisms to handle the distribution of keys for use by 250 USM. The more important issue is that operators wanted to leverage 251 existing user base infrastructures that were not specific to SNMP. 253 A USM-compliant architecture might combine the authentication 254 mechanism with an external mechanism, such as RADIUS [RFC2865] to 255 provide the authentication service. Similarly it might be possible 256 to utilize an external protocol to encrypt a message, to check 257 timeliness, to check data integrity, etc. However this corresponds 258 to the second approach - requiring the coordination of a number of 259 differently subcontracted services. Building solid security between 260 the various services is difficult, and there is a significant 261 potential for gaps in security. 263 An alternative approach might be to utilize one or more lower-layer 264 security mechanisms to provide the message-oriented security services 265 required. These would include authentication of the sender, 266 encryption, timeliness checking, and data integrity checking. This 267 corresponds to the third approach described above. There are a 268 number of IETF standards available or in development to address these 269 problems through security layers at the transport layer or 270 application layer, among them TLS [RFC5246], SASL [RFC4422], and SSH 271 [RFC4251] 273 From an operational perspective, it is highly desirable to use 274 security mechanisms that can unify the administrative security 275 management for SNMPv3, command line interfaces (CLIs) and other 276 management interfaces. The use of security services provided by 277 lower layers is the approach commonly used for the CLI, and is also 278 the approach being proposed for other network management protocols, 279 such as syslog [I-D.ietf-syslog-protocol] and NETCONF [RFC4741]. 281 This document defines a Transport Subsystem extension to the RFC3411 282 architecture based on the third approach. This extension specifies 283 how other lower layer protocols with common security infrastructures 284 can be used underneath the SNMP protocol and the desired goal of 285 unified administrative security can be met. 287 This extension allows security to be provided by an external protocol 288 connected to the SNMP engine through an SNMP Transport Model 289 [RFC3417]. Such a Transport Model would then enable the use of 290 existing security mechanisms such as (TLS) [RFC5246] or SSH [RFC4251] 291 within the RFC3411 architecture. 293 There are a number of Internet security protocols and mechanisms that 294 are in wide spread use. Many of them try to provide a generic 295 infrastructure to be used by many different application layer 296 protocols. The motivation behind the Transport Subsystem is to 297 leverage these protocols where it seems useful. 299 There are a number of challenges to be addressed to map the security 300 provided by a secure transport into the SNMP architecture so that 301 SNMP continues to provide interoperability with existing 302 implementations. These challenges are described in detail in this 303 document. For some key issues, design choices are described that 304 might be made to provide a workable solution that meets operational 305 requirements and fits into the SNMP architecture defined in 306 [RFC3411]. 308 3. Requirements of a Transport Model 310 3.1. Message Security Requirements 312 Transport security protocols SHOULD provide protection against the 313 following message-oriented threats: 315 1. modification of information 317 2. masquerade 319 3. message stream modification 321 4. disclosure 323 These threats are described in section 1.4 of [RFC3411]. It is not 324 required to protect against denial of service or traffic analysis, 325 but it should not make those threats significantly worse. 327 3.1.1. Security Protocol Requirements 329 There are a number of standard protocols that could be proposed as 330 possible solutions within the Transport Subsystem. Some factors 331 should be considered when selecting a protocol. 333 Using a protocol in a manner for which it was not designed has 334 numerous problems. The advertised security characteristics of a 335 protocol might depend on it being used as designed; when used in 336 other ways, it might not deliver the expected security 337 characteristics. It is recommended that any proposed model include a 338 description of the applicability of the Transport Model. 340 A Transport Model SHOULD NOT require modifications to the underlying 341 protocol. Modifying the protocol might change its security 342 characteristics in ways that could impact other existing usages. If 343 a change is necessary, the change SHOULD be an extension that has no 344 impact on the existing usages. Any Transport Model SHOULD include a 345 description of potential impact on other usages of the protocol. 347 Since multiple transport models can exist simultaneously within the 348 transport subsystem, transport models MUST be able to coexist with 349 each other. 351 3.2. SNMP Requirements 352 3.2.1. Architectural Modularity Requirements 354 SNMP version 3 (SNMPv3) is based on a modular architecture (defined 355 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 356 standards over time, and to minimize side effects between subsystems 357 when changes are made. 359 The RFC3411 architecture includes a Message Processing Subsystem 360 permitting different message versions to be handled by a single 361 engine, a Security Subsystem for enabling different methods of 362 providing security services, Applications(s) to support different 363 types of application processors, and an Access Control Subsystem for 364 allowing multiple approaches to access control. The RFC3411 365 architecture does not include a subsystem for Transport Models, 366 despite the fact there are multiple transport mappings already 367 defined for SNMP [RFC3417]. This document describes a Transport 368 Subsystem that is compatible with the RFC3411 architecture. As work 369 is being done to use secure transports such as SSH and TLS, using a 370 subsystem will enable consistent design and modularity of such 371 Transport Models. 373 The design of this Transport Subsystem accepts the goals of the 374 RFC3411 architecture defined in section 1.5 of [RFC3411]. This 375 Transport Subsystem uses a modular design that permits Transport 376 Models (which may or may not be security-aware) to be "plugged into" 377 the RFC3411 architecture. Such Transport Models would be independent 378 of other modular SNMP components as much as possible. This design 379 also permits Transport Models to be advanced through the standards 380 process independently of other Transport Models. 382 To encourage a basic level of interoperability, any Transport Model 383 SHOULD define one mandatory-to-implement security mechanism, but 384 should also be able to support additional existing and new 385 mechanisms. 387 The following diagram depicts the SNMPv3 architecture including the 388 new Transport Subsystem defined in this document, and a new Transport 389 Security Model defined in [I-D.ietf-isms-transport-security-model]. 391 +------------------------------+ 392 | Network | 393 +------------------------------+ 394 ^ ^ ^ 395 | | | 396 v v v 397 +-------------------------------------------------------------------+ 398 | +--------------------------------------------------+ | 399 | | Transport Subsystem | | 400 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 401 | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | 402 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 403 | +--------------------------------------------------+ | 404 | ^ | 405 | | | 406 | Dispatcher v | 407 | +-------------------+ +---------------------+ +----------------+ | 408 | | Transport | | Message Processing | | Security | | 409 | | Dispatch | | Subsystem | | Subsystem | | 410 | | | | +------------+ | | +------------+ | | 411 | | | | +->| v1MP |<--->| | USM | | | 412 | | | | | +------------+ | | +------------+ | | 413 | | | | | +------------+ | | +------------+ | | 414 | | | | +->| v2cMP |<--->| | Transport | | | 415 | | Message | | | +------------+ | | | Security | | | 416 | | Dispatch <--------->| +------------+ | | | Model | | | 417 | | | | +->| v3MP |<--->| +------------+ | | 418 | | | | | +------------+ | | +------------+ | | 419 | | PDU Dispatch | | | +------------+ | | | Other | | | 420 | +-------------------+ | +->| otherMP |<--->| | Model(s) | | | 421 | ^ | +------------+ | | +------------+ | | 422 | | +---------------------+ +----------------+ | 423 | v | 424 | +-------+-------------------------+---------------+ | 425 | ^ ^ ^ | 426 | | | | | 427 | v v v | 428 | +-------------+ +---------+ +--------------+ +-------------+ | 429 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 430 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 431 | | application | | | | applications | | application | | 432 | +-------------+ +---------+ +--------------+ +-------------+ | 433 | ^ ^ | 434 | | | | 435 | v v | 436 | +----------------------------------------------+ | 437 | | MIB instrumentation | SNMP entity | 438 +-------------------------------------------------------------------+ 440 3.2.1.1. Changes to the RFC3411 Architecture 442 The RFC3411 architecture and the Security Subsystem assume that a 443 Security Model is called by a Message Processing Model and will 444 perform multiple security functions within the Security Subsystem. A 445 Transport Model that supports a secure transport protocol might 446 perform similar security functions within the Transport Subsystem, 447 including the translation of transport security parameters to/from 448 security-model-independent parameters. 450 To accommodate this, an implementation-specific cache of transport- 451 specific information will be described (not shown), and the data 452 flows on this path will be extended to pass security-model- 453 independent values. This document amends some of the ASIs defined in 454 RFC 3411, and these changes are covered in section 6. 456 New Security Models may be defined that understand how to work with 457 these modified ASIs and the transport-information cache. One such 458 Security Model, the Transport Security Model, is defined in 459 [I-D.ietf-isms-transport-security-model]. 461 3.2.1.2. Changes to RFC3411 processing 463 The introduction of secure transports affects the responsibilities 464 and order of processing within the RFC3411 architecture. While the 465 steps are the same, they may occur in a different order, and may be 466 done by different subsystems. With the existing RFC3411 467 architecture, security processing starts when the Message Processing 468 Model decodes portions of the encoded message to extract parameters 469 that identify which Security Model should handle the security-related 470 tasks. 472 A secure transport performs those security functions on the message, 473 before the message is decoded. Some of these functions might then be 474 repeated by the selected Security Model. 476 3.2.1.3. Passing Information between SNMP Engines 478 A secure Transport Model will establish an authenticated and possibly 479 encrypted tunnel between the Transport Models of two SNMP engines. 480 After a transport layer tunnel is established, then SNMP messages can 481 be sent through the tunnel from one SNMP engine to the other. While 482 the Community Security Models [RFC3584] and the User-based Security 483 Model establish a security association for each SNMP message, newer 484 Transport Models MAY support sending multiple SNMP messages through 485 the same tunnel to amortize the costs of establishing a security 486 association. 488 3.2.2. Access Control Requirements 490 RFC3411 made some design decisions related to the support of an 491 Access Control Subsystem. These include establishing and passing in 492 a model-independent manner the securityModel, securityName and 493 securityLevel parameters, and separating message authentication from 494 data access authorization. 496 3.2.2.1. securityName and securityLevel Mapping 498 SNMP data access controls are expected to work on the basis of who 499 can perform what operations on which subsets of data, and based on 500 the security services that will be provided to secure the data in 501 transit. The securityModel and securityLevel parameters establish 502 the protections for transit - whether authentication and privacy 503 services will be or have been applied to the message. The 504 securityName is a model-independent identifier of the security 505 "principal". 507 A Security Model plays a role in security that goes beyond protecting 508 the message - it provides a mapping between the security-model- 509 specific principal for an incoming message to a security-model 510 independent securityName which can be used for subsequent processing, 511 such as for access control. The securityName is mapped from a 512 mechanism-specific identity, and this mapping must be done for 513 incoming messages by the Security Model before it passes securityName 514 to the Message Processing Model via the processIncoming ASI. 516 A Security Model is also responsible to specify, via the 517 securityLevel parameter, whether incoming messages have been 518 authenticated and encrypted, and to ensure that outgoing messages are 519 authenticated and encrypted based on the value of securityLevel. 521 A Transport Model MAY provide suggested values for securityName and 522 securityLevel. A Security Model may have multiple sources for 523 determining the principal and desired security services, and a 524 particular Security Model may or may not utilize the values proposed 525 by a Transport Model when deciding the value of securityName and 526 securityLevel. 528 Documents defining a new transport domain MUST define a prefix that 529 MAY be prepended by the Security Model to all passed securityNames. 530 The prefix MUST include from one to four ASCII characters, not 531 including a ":" (ASCII 0x3a) character. If a prefix is used, a 532 securityName is constructed by concatenating the prefix and a ":" 533 (ASCII 0x3a) character followed by a non-empty identity in an 534 snmpAdminString compatible format. Transport domains and their 535 corresponding prefixes are coordinated via the IANA registry "SNMP 536 Transport Domains". 538 3.2.3. Security Parameter Passing Requirements 540 A Message Processing Model might unpack SNMP-specific security 541 parameters from an incoming message before calling a specific 542 Security Model to handle the security-related processing of the 543 message. When using a secure Transport Model, some security 544 parameters might be extracted from the transport layer by the 545 Transport Model before the message is passed to the Message 546 Processing Subsystem. 548 This document describes a cache mechanism (see Section 5), into which 549 the Transport Model puts information about the transport and security 550 parameters applied to a transport connection or an incoming message, 551 and a Security Model may extract that information from the cache. A 552 tmStateReference is passed as an extra parameter in the ASIs between 553 the Transport Subsystem, the Message Processing and Security 554 Subsystems, to identify the relevant cache. This approach of passing 555 a model-independent reference is consistent with the 556 securityStateReference cache already being passed around in the 557 RFC3411 ASIs. 559 3.2.4. Separation of Authentication and Authorization 561 The RFC3411 architecture defines a separation of authentication and 562 the authorization to access and/or modify MIB data. A set of model- 563 independent parameters (securityModel, securityName, and 564 securityLevel) are passed between the Security Subsystem, the 565 applications, and the Access Control Subsystem. 567 This separation was a deliberate decision of the SNMPv3 WG, to allow 568 support for authentication protocols which do not provide data access 569 authorization capabilities, and to support data access authorization 570 schemes, such as VACM, that do not perform their own authentication. 572 A Message Processing Model determines which Security Model is used, 573 either based on the message version, e.g., SNMPv1 and SNMPv2c, or 574 possibly by a value specified in the message, e.g., msgSecurityModel 575 field in SNMPv3. 577 The Security Model makes the decision which securityName and 578 securityLevel values are passed as model-independent parameters to an 579 application, which then passes them via the isAccessAllowed ASI to 580 the Access Control Subsystem. 582 An Access Control Model performs the mapping from the model- 583 independent security parameters to a policy within the Access Control 584 Model that is access-control-model-dependent. 586 A Transport Model does not know which Security Model will be used for 587 an incoming message, so cannot know how the securityName and 588 securityLevel parameters will be determined. It can propose an 589 authenticated identity (via the tmSecurityName field), but there is 590 no guarantee that this value will be used by the Security Model. For 591 example, non-transport-aware Security Models will typically determine 592 the securityName (and securityLevel) based on the contents of the 593 SNMP message itself. Such Security Models will simply not know that 594 the tmStateReference cache exists. 596 Further, even if the Transport Model can influence the choice of 597 securityName, it cannot directly determine the authorization allowed 598 to this identity. If two different Transport Models each 599 authenticate a transport principal, that are then both mapped to the 600 same securityName, then these two identities will typically be 601 afforded exactly the same authorization by the Access Control Model. 603 The only way for the Access Control Model to differentiate between 604 identities based on the underlying Transport Model, would be for such 605 transport-authenticated identities to be mapped to distinct 606 securityNames. How and if this is done is Security-Model-dependent. 608 3.3. Session Requirements 610 Some secure transports have a notion of sessions, while other secure 611 transports provide channels or other session-like mechanism. 612 Throughout this document, the term session is used in a broad sense 613 to cover transport sessions, transport channels, and other transport- 614 layer session-like mechanisms. Transport-layer sessions that can 615 secure multiple SNMP messages within the lifetime of the session are 616 considered desirable because the cost of authentication can be 617 amortized over potentially many transactions. How a transport 618 session is actually established, opened, closed, or maintained is 619 specific to a particular Transport Model. 621 To reduce redundancy, this document describes aspects that are 622 expected to be common to all Transport Model sessions. 624 3.3.1. No SNMP Sessions 626 The architecture defined in [RFC3411] and the Transport Subsystem 627 defined in this document do not support SNMP sessions or include a 628 session selector in the Abstract Service Interfaces. 630 The Transport Subsystem may support transport sessions. However, the 631 transport subsystem does not have access to the pduType (i.e., the 632 SNMP operation type), so cannot select a given transport session for 633 particular types of traffic. 635 Certain parameters of the Abstract Service Interfaces might be used 636 to guide the selection of an appropriate transport session to use for 637 a given request by an application. 639 The transportDomain and transportAddress identify the transport 640 connection to a remote network node. Elements of the transport 641 address (such as the port number) might be used by an application to 642 send a particular PDU type to a particular transport address. For 643 example, the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are 644 used to configure notification originators with the destination port 645 to which SNMPv2-Trap PDUs or Inform PDUs should be sent, but the 646 transport subsystem never looks inside the PDU. 648 The securityName identifies which security principal to communicate 649 with at that address (e.g., different NMS applications), and the 650 securityLevel might permit selection of different sets of security 651 properties for different purposes (e.g., encrypted SETs vs. non- 652 encrypted GETs). 654 However, because the handling of transport sessions is specific to 655 each transport model, some transport models MAY restrict selecting a 656 particular transport session. A user application might use a unique 657 combination of transportDomain, transportAddress, securityModel, 658 securityName, and securityLevel to try to force the selection of a 659 given transport session. This usage is NOT RECOMMENDED because it is 660 not guaranteed to be interoperable across implementations and across 661 models. 663 Implementations SHOULD be able to maintain some reasonable number of 664 concurrent transport sessions, and MAY provide non-standard internal 665 mechanisms to select transport sessions. 667 3.3.2. Session Establishment Requirements 669 SNMP applications provide the transportDomain, transportAddress, 670 securityName, and securityLevel to be used to create a new session. 672 If the Transport Model cannot provide at least the requested level of 673 security, the Transport Model SHOULD discard the message and SHOULD 674 notify the dispatcher that establishing a session and sending the 675 message failed. Similarly, if the session cannot be established, 676 then the message SHOULD be discarded and the dispatcher notified. 678 Transport session establishment might require provisioning 679 authentication credentials at an engine, either statically or 680 dynamically. How this is done is dependent on the transport model 681 and the implementation. 683 3.3.3. Session Maintenance Requirements 685 A Transport Model can tear down sessions as needed. It might be 686 necessary for some implementations to tear down sessions as the 687 result of resource constraints, for example. 689 The decision to tear down a session is implementation-dependent. How 690 an implementation determines that an operation has completed is 691 implementation-dependent. While it is possible to tear down each 692 transport session after processing for each message has completed, 693 this is not recommended for performance reasons. 695 The elements of procedure describe when cached information can be 696 discarded, and the timing of cache cleanup might have security 697 implications, but cache memory management is an implementation issue. 699 If a Transport Model defines MIB module objects to maintain session 700 state information, then the Transport Model MUST define what SHOULD 701 happen to the objects when a related session is torn down, since this 702 will impact interoperability of the MIB module. 704 3.3.4. Message security versus session security 706 A Transport Model session is associated with state information that 707 is maintained for its lifetime. This state information allows for 708 the application of various security services to multiple messages. 709 Cryptographic keys associated with the transport session SHOULD be 710 used to provide authentication, integrity checking, and encryption 711 services, as needed, for data that is communicated during the 712 session. The cryptographic protocols used to establish keys for a 713 Transport Model session SHOULD ensure that fresh new session keys are 714 generated for each session. This would ensure that a cross-session 715 replay attack would be unsuccessful; that is, an attacker could not 716 take a message observed on one session, and successfully replay this 717 on another session. 719 A good security protocol would also protect against replay attacks 720 within a session; that is, an attacker could not take a message 721 observed on a session, and successfully replay this later in the same 722 session. One approach would be to use sequence information within 723 the protocol, allowing the participants to detect if messages were 724 replayed or reordered within a session. 726 If a secure transport session is closed between the time a request 727 message is received, and the corresponding response message is sent, 728 then the response message SHOULD be discarded, even if a new session 729 has been established. The SNMPv3 WG decided that this should be a 730 SHOULD architecturally, and it is a security-model-specific decision 731 whether to REQUIRE this. The architecture does not mandate this 732 requirement to allow for future security models where this might make 733 sense, but not requiring this could lead to added complexity and 734 security vulnerabilities, so most security models SHOULD require 735 this. 737 SNMPv3 was designed to support multiple levels of security, 738 selectable on a per-message basis by an SNMP application, because, 739 for example, there is not much value in using encryption for a 740 Command Generator to poll for potentially non-sensitive performance 741 data on thousands of interfaces every ten minutes; the encryption 742 might add significant overhead to processing of the messages. 744 Some Transport Models might support only specific authentication and 745 encryption services, such as requiring all messages to be carried 746 using both authentication and encryption, regardless of the security 747 level requested by an SNMP application. A Transport Model MAY 748 upgrade the security level requested by a transport-aware security 749 model, i.e. noAuthNoPriv and authNoPriv might be sent over an 750 authenticated and encrypted session. A Transport Model MUST NOT 751 downgrade the security level requested by a transport-aware security 752 model, and SHOULD discard any message where this would occur. 754 4. Scenario Diagrams and the Transport Subsystem 756 RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to 757 illustrate how an outgoing message is created, and how an incoming 758 message is processed. RFC3411 does not define ASIs for the "Send 759 SNMP Request Message to Network", "Receive SNMP Response Message from 760 Network", "Receive SNMP Message from Network" and "Send SNMP message 761 to Network" arrows in these diagrams. 763 This document defines two ASIs corresponding to these arrows: a 764 sendMessage ASI to send SNMP messages to the network, and a 765 receiveMessage ASI to receive SNMP messages from the network. These 766 ASIs are used for all SNMP messages, regardless of pduType. 768 5. Cached Information and References 770 When performing SNMP processing, there are two levels of state 771 information that may need to be retained: the immediate state linking 772 a request-response pair, and potentially longer-term state relating 773 to transport and security. 775 The RFC3411 architecture uses caches to maintain the short-term 776 message state, and uses references in the ASIs to pass this 777 information between subsystems. 779 This document defines the requirements for a cache to handle 780 additional short-term message state and longer-term transport state 781 information, using a tmStateReference parameter to pass this 782 information between subsystems. 784 To simplify the elements of procedure, the release of state 785 information is not always explicitly specified. As a general rule, 786 if state information is available when a message being processed gets 787 discarded, the state related to that message SHOULD also be 788 discarded. If state information is available when a relationship 789 between engines is severed, such as the closing of a transport 790 session, the state information for that relationship SHOULD also be 791 discarded. 793 Since the contents of a cache are meaningful only within an 794 implementation, and not on-the-wire, the format of the cache is 795 implementation-specific. 797 5.1. securityStateReference 799 The securityStateReference parameter is defined in RFC3411. Its 800 primary purpose is to provide a mapping between a request and the 801 corresponding response. This cache is not accessible to Transport 802 Models, and an entry is typically only retained for the lifetime of a 803 request-response pair of messages. 805 5.2. tmStateReference 807 For each transport session, information about the transport security 808 is stored in a tmState cache or datastore, that is referenced by a 809 tmStateReference. The tmStateReference parameter is used to pass 810 model-specific and mechanism-specific parameters between the 811 Transport subsystem and transport-aware Security Models. 813 In general, when necessary, the tmState is populated by the security 814 model for outgoing messages and by the transport model for incoming 815 messages. However, in both cases, the model populating the tmState 816 may have incomplete information, and the missing information might be 817 populated by the other model when the information becomes available. 819 The tmState might contain both long-term and short-term information. 820 The session information typically remains valid for the duration of 821 the transport session, might be used for several messages, and might 822 be stored in a local configuration datastore. Some information has a 823 shorter lifespan, such as tmSameSecurity and tmRequestedSecurityLevel 824 which are associated with a specific message. 826 Since this cache is only used within an implementation, and not on- 827 the-wire, the precise contents and format of the cache are 828 implementation-dependent. For architectural modularity between 829 Transport Models and transport-aware Security Models, a fully-defined 830 tmState MUST conceptually include at least the following fields: 832 tmTransportDomain 834 tmTransportAddress 836 tmSecurityName 838 tmRequestedSecurityLevel 840 tmTransportSecurityLevel 842 tmSameSecurity 844 tmSessionID 846 The details of these fields are described in the following 847 subsections. 849 5.2.1. Transport information 851 Information about the source of an incoming SNMP message is passed up 852 from the Transport subsystem as far as the Message Processing 853 subsystem. However these parameters are not included in the 854 processIncomingMsg ASI defined in RFC3411, and hence this information 855 is not directly available to the Security Model. 857 A transport-aware Security Model might wish to take account of the 858 transport protocol and originating address when authenticating the 859 request, and setting up the authorization parameters. It is 860 therefore necessary for the Transport Model to include this 861 information in the tmStateReference cache, so that it is accessible 862 to the Security Model. 864 o tmTransportDomain: the transport protocol (and hence the Transport 865 Model) used to receive the incoming message 867 o tmTransportAddress: the source of the incoming message. 869 The ASIs used for processing an outgoing message all include explicit 870 transportDomain and transportAddress parameters. The values within 871 the securityStateReference cache might override these parameters for 872 outgoing messages. 874 5.2.2. securityName 876 There are actually three distinct "identities" that can be identified 877 during the processing of an SNMP request over a secure transport: 879 o transport principal: the transport-authenticated identity, on 880 whose behalf the secure transport connection was (or should be) 881 established. This value is transport-, mechanism- and 882 implementation- specific, and is only used within a given 883 Transport Model. 885 o tmSecurityName: a human-readable name (in snmpAdminString format) 886 representing this transport identity. This value is transport- 887 and implementation-specific, and is only used (directly) by the 888 Transport and Security Models. 890 o securityName: a human-readable name (in snmpAdminString format) 891 representing the SNMP principal in a model-independent manner. 892 This value is used directly by SNMP Applications, the access 893 control subsystem, the message processing subsystem, and the 894 security subsystem. 896 The transport principal may or may not be the same as the 897 tmSecurityName. Similarly, the tmSecurityName may or may not be the 898 same as the securityName as seen by the Application and Access 899 Control subsystems. In particular, a non-transport-aware Security 900 Model will ignore tmSecurityName completely when determining the SNMP 901 securityName. 903 However it is important that the mapping between the transport 904 principal and the SNMP securityName (for transport-aware Security 905 Models) is consistent and predictable, to allow configuration of 906 suitable access control and the establishment of transport 907 connections. 909 5.2.3. securityLevel 911 There are two distinct issues relating to security level as applied 912 to secure transports. For clarity, these are handled by separate 913 fields in the tmStateReference cache: 915 o tmTransportSecurityLevel: an indication from the Transport Model 916 of the level of security offered by this session. The Security 917 Model can use this to ensure that incoming messages were suitably 918 protected before acting on them. 920 o tmRequestedSecurityLevel: an indication from the Security Model of 921 the level of security required to be provided by the transport 922 protocol. The Transport Model can use this to ensure that 923 outgoing messages will not be sent over an insufficiently secure 924 session. 926 5.2.4. Session Information 928 For security reasons, if a secure transport session is closed between 929 the time a request message is received and the corresponding response 930 message is sent, then the response message SHOULD be discarded, even 931 if a new session has been established. The SNMPv3 WG decided that 932 this should be a SHOULD architecturally, and it is a security-model- 933 specific decision whether to REQUIRE this. 935 o tmSameSecurity: this flag is used by a transport-aware Security 936 Model to indicate whether the Transport Model MUST enforce this 937 restriction. 939 o tmSessionID: in order to verify whether the session has changed, 940 the Transport Model must be able to compare the session used to 941 receive the original request with the one to be used to send the 942 response. This typically requires some form of session 943 identifier. This value is only ever used by the Transport Model, 944 so the format and interpretation of this field are model-specific 945 and implementation-dependent. 947 When processing an outgoing message, if tmSameSecurity is true, then 948 the tmSessionID MUST match the current transport session, otherwise 949 the message MUST be discarded, and the dispatcher notified that 950 sending the message failed. 952 6. Abstract Service Interfaces 954 Abstract service interfaces have been defined by RFC 3411 to describe 955 the conceptual data flows between the various subsystems within an 956 SNMP entity, and to help keep the subsystems independent of each 957 other except for the common parameters. 959 This document introduces a couple of new ASIs to define the interface 960 between the Transport and Dispatcher Subsystems, and extends some of 961 the ASIs defined in RFC3411 to include transport-related information. 963 This document follows the example of RFC3411 regarding the release of 964 state information, and regarding error indications. 966 1) The release of state information is not always explicitly 967 specified in a transport model. As a general rule, if state 968 information is available when a message gets discarded, the message- 969 state information should also be released, and if state information 970 is available when a session is closed, the session state information 971 should also be released. Keeping sensitive security information 972 longer than necessary might introduce potential vulnerabilities to an 973 implementation. 975 2)An error indication in statusInformation will typically include the 976 OID and value for an incremented error counter. This may be 977 accompanied by values for contextEngineID and contextName for this 978 counter, a value for securityLevel, and the appropriate state 979 reference if the information is available at the point where the 980 error is detected. 982 6.1. sendMessage ASI 984 The sendMessage ASI is used to pass a message from the Dispatcher to 985 the appropriate Transport Model for sending. In the diagram in 986 section 4.6.1 of RFC 3411, the sendMessage ASI defined in this 987 document replaces the text "Send SNMP Request Message to Network". 988 In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP 989 Message to Network" 991 If present and valid, the tmStateReference refers to a cache 992 containing transport-model-specific parameters for the transport and 993 transport security. How a tmStateReference is determined to be 994 present and valid is implementation-dependent. How the information 995 in the cache is used is transport-model-dependent and implementation- 996 dependent. 998 This may sound underspecified, but a transport model might be 999 something like SNMP over UDP over IPv6, where no security is 1000 provided, so it might have no mechanisms for utilizing a 1001 tmStateReference cache. 1003 statusInformation = 1004 sendMessage( 1005 IN destTransportDomain -- transport domain to be used 1006 IN destTransportAddress -- transport address to be used 1007 IN outgoingMessage -- the message to send 1008 IN outgoingMessageLength -- its length 1009 IN tmStateReference -- reference to transport state 1010 ) 1012 6.2. Changes to RFC3411 Outgoing ASIs 1014 Additional parameters have been added to the ASIs defined in RFC3411, 1015 concerned with communication between the Dispatcher and Message 1016 Processing subsystems, and between the Message Processing and 1017 Security Subsystems. 1019 6.2.1. Message Processing Subsystem Primitives 1021 A tmStateReference parameter has been added as an OUT parameter to 1022 the prepareOutgoingMessage and prepareResponseMessage ASIs. This is 1023 passed from Message Processing Subsystem to the dispatcher, and from 1024 there to the Transport Subsystem. 1026 How or if the Message Processing Subsystem modifies or utilizes the 1027 contents of the cache is message-processing-model specific. 1029 statusInformation = -- success or errorIndication 1030 prepareOutgoingMessage( 1031 IN transportDomain -- transport domain to be used 1032 IN transportAddress -- transport address to be used 1033 IN messageProcessingModel -- typically, SNMP version 1034 IN securityModel -- Security Model to use 1035 IN securityName -- on behalf of this principal 1036 IN securityLevel -- Level of Security requested 1037 IN contextEngineID -- data from/at this entity 1038 IN contextName -- data from/in this context 1039 IN pduVersion -- the version of the PDU 1040 IN PDU -- SNMP Protocol Data Unit 1041 IN expectResponse -- TRUE or FALSE 1042 IN sendPduHandle -- the handle for matching 1043 incoming responses 1044 OUT destTransportDomain -- destination transport domain 1045 OUT destTransportAddress -- destination transport address 1046 OUT outgoingMessage -- the message to send 1047 OUT outgoingMessageLength -- its length 1048 OUT tmStateReference -- (NEW) reference to transport state 1049 ) 1051 statusInformation = -- success or errorIndication 1052 prepareResponseMessage( 1053 IN messageProcessingModel -- typically, SNMP version 1054 IN securityModel -- Security Model to use 1055 IN securityName -- on behalf of this principal 1056 IN securityLevel -- Level of Security requested 1057 IN contextEngineID -- data from/at this entity 1058 IN contextName -- data from/in this context 1059 IN pduVersion -- the version of the PDU 1060 IN PDU -- SNMP Protocol Data Unit 1061 IN maxSizeResponseScopedPDU -- maximum size able to accept 1062 IN stateReference -- reference to state information 1063 -- as presented with the request 1064 IN statusInformation -- success or errorIndication 1065 -- error counter OID/value if error 1066 OUT destTransportDomain -- destination transport domain 1067 OUT destTransportAddress -- destination transport address 1068 OUT outgoingMessage -- the message to send 1069 OUT outgoingMessageLength -- its length 1070 OUT tmStateReference -- (NEW) reference to transport state 1071 ) 1073 6.2.2. Security Subsystem Primitives 1075 transportDomain and transportAddress parameters have been added as IN 1076 parameters to the generateRequestMsg and generateResponseMsg ASIs, 1077 and a tmStateReference parameter has been added as an OUT parameter. 1078 The transportDomain and transportAddress parameters will have been 1079 passed into the Message Processing Subsystem from the dispatcher, and 1080 are passed on to the Security Subsystem. The tmStateReference 1081 parameter will be passed from the Security Subsystem back to the 1082 Message Processing Subsystem, and on to the dispatcher and Transport 1083 subsystems. 1085 If a cache exists for a session identifiable from the 1086 tmTransportDomain, tmTransportAddress, tmSecurityName and requested 1087 securityLevel, then a transport-aware Security Model might create a 1088 tmStateReference parameter to this cache, and pass that as an OUT 1089 parameter. 1091 statusInformation = 1092 generateRequestMsg( 1093 IN transportDomain -- (NEW) destination transport domain 1094 IN transportAddress -- (NEW) destination transport address 1095 IN messageProcessingModel -- typically, SNMP version 1096 IN globalData -- message header, admin data 1097 IN maxMessageSize -- of the sending SNMP entity 1098 IN securityModel -- for the outgoing message 1099 IN securityEngineID -- authoritative SNMP entity 1100 IN securityName -- on behalf of this principal 1101 IN securityLevel -- Level of Security requested 1102 IN scopedPDU -- message (plaintext) payload 1103 OUT securityParameters -- filled in by Security Module 1104 OUT wholeMsg -- complete generated message 1105 OUT wholeMsgLength -- length of generated message 1106 OUT tmStateReference -- (NEW) reference to transport state 1107 ) 1109 statusInformation = 1110 generateResponseMsg( 1111 IN transportDomain -- (NEW) destination transport domain 1112 IN transportAddress -- (NEW) destination transport address 1113 IN messageProcessingModel -- Message Processing Model 1114 IN globalData -- msgGlobalData 1115 IN maxMessageSize -- from msgMaxSize 1116 IN securityModel -- as determined by MPM 1117 IN securityEngineID -- the value of snmpEngineID 1118 IN securityName -- on behalf of this principal 1119 IN securityLevel -- for the outgoing message 1120 IN scopedPDU -- as provided by MPM 1121 IN securityStateReference -- as provided by MPM 1122 OUT securityParameters -- filled in by Security Module 1123 OUT wholeMsg -- complete generated message 1124 OUT wholeMsgLength -- length of generated message 1125 OUT tmStateReference -- (NEW) reference to transport state 1126 ) 1128 6.3. The receiveMessage ASI 1130 The receiveMessage ASI is used to pass a message from the Transport 1131 Subsystem to the Dispatcher. In the diagram in section 4.6.1 of RFC 1132 3411, the receiveMessage ASI replaces the text "Receive SNMP Response 1133 Message from Network". In section 4.6.2, the receiveMessage ASI 1134 replaces the text "Receive SNMP Message from Network". 1136 When a message is received on a given transport session, if a cache 1137 does not already exist for that session, the Transport Model might 1138 create one, referenced by tmStateReference. The contents of this 1139 cache are discussed in section 5. How this information is determined 1140 is implementation- and transport-model-specific. 1142 "Might create one" may sound underspecified, but a transport model 1143 might be something like SNMP over UDP over IPv6, where transport 1144 security is not provided, so it might not create a cache. 1146 The Transport Model does not know the securityModel for an incoming 1147 message; this will be determined by the Message Processing Model in a 1148 message-processing-model-dependent manner. 1150 statusInformation = 1151 receiveMessage( 1152 IN transportDomain -- origin transport domain 1153 IN transportAddress -- origin transport address 1154 IN incomingMessage -- the message received 1155 IN incomingMessageLength -- its length 1156 IN tmStateReference -- reference to transport state 1157 ) 1159 6.4. Changes to RFC3411 Incoming ASIs 1161 The tmStateReference parameter has also been added to some of the 1162 incoming ASIs defined in RFC3411. How or if a Message Processing 1163 Model or Security Model uses tmStateReference is message-processing- 1164 and security-model-specific. 1166 This may sound underspecified, but a message processing model might 1167 have access to all the information from the cache and from the 1168 message. The Message Processing Model might determine that the USM 1169 Security Model is specified in an SNMPv3 message header; the USM 1170 Security Model has no need of values in the tmStateReference cache to 1171 authenticate and secure the SNMP message, but an application might 1172 have specified to use a secure transport such as that provided by the 1173 SSH Transport Model to send the message to its destination. 1175 6.4.1. Message Processing Subsystem Primitive 1177 The tmStateReference parameter of prepareDataElements is passed from 1178 the dispatcher to the Message Processing Subsystem. How or if the 1179 Message Processing Subsystem modifies or utilizes the contents of the 1180 cache is message-processing-model-specific. 1182 result = -- SUCCESS or errorIndication 1183 prepareDataElements( 1184 IN transportDomain -- origin transport domain 1185 IN transportAddress -- origin transport address 1186 IN wholeMsg -- as received from the network 1187 IN wholeMsgLength -- as received from the network 1188 IN tmStateReference -- (NEW) from the Transport Model 1189 OUT messageProcessingModel -- typically, SNMP version 1190 OUT securityModel -- Security Model to use 1191 OUT securityName -- on behalf of this principal 1192 OUT securityLevel -- Level of Security requested 1193 OUT contextEngineID -- data from/at this entity 1194 OUT contextName -- data from/in this context 1195 OUT pduVersion -- the version of the PDU 1196 OUT PDU -- SNMP Protocol Data Unit 1197 OUT pduType -- SNMP PDU type 1198 OUT sendPduHandle -- handle for matched request 1199 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1200 OUT statusInformation -- success or errorIndication 1201 -- error counter OID/value if error 1202 OUT stateReference -- reference to state information 1203 -- to be used for possible Response 1204 ) 1206 6.4.2. Security Subsystem Primitive 1208 The processIncomingMessage ASI passes tmStateReference from the 1209 Message Processing Subsystem to the Security Subsystem. 1211 If tmStateReference is present and valid, an appropriate Security 1212 Model might utilize the information in the cache. How or if the 1213 Security Subsystem utilizes the information in the cache is security- 1214 model-specific. 1216 statusInformation = -- errorIndication or success 1217 -- error counter OID/value if error 1218 processIncomingMsg( 1219 IN messageProcessingModel -- typically, SNMP version 1220 IN maxMessageSize -- of the sending SNMP entity 1221 IN securityParameters -- for the received message 1222 IN securityModel -- for the received message 1223 IN securityLevel -- Level of Security 1224 IN wholeMsg -- as received on the wire 1225 IN wholeMsgLength -- length as received on the wire 1226 IN tmStateReference -- (NEW) from the Transport Model 1227 OUT securityEngineID -- authoritative SNMP entity 1228 OUT securityName -- identification of the principal 1229 OUT scopedPDU, -- message (plaintext) payload 1230 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1231 OUT securityStateReference -- reference to security state 1232 ) -- information, needed for response 1234 7. Security Considerations 1236 This document defines an architectural approach that permits SNMP to 1237 utilize transport layer security services. Each proposed Transport 1238 Model should discuss the security considerations of that Transport 1239 Model. 1241 It is considered desirable by some industry segments that SNMP 1242 Transport Models should utilize transport layer security that 1243 addresses perfect forward secrecy at least for encryption keys. 1244 Perfect forward secrecy guarantees that compromise of long term 1245 secret keys does not result in disclosure of past session keys. Each 1246 proposed Transport Model should include a discussion in its security 1247 considerations of whether perfect forward security is appropriate for 1248 that Transport Model. 1250 The Denial of Service characteristics of various transport models and 1251 security protocols will vary and should be evaluated when determining 1252 the applicability of a transport model to a particular deployment 1253 situation. 1255 Since the cache will contain security-related parameters, 1256 implementers should store this information (in memory or in 1257 persistent storage) in a manner to protect it from unauthorized 1258 disclosure and/or modification. 1260 Care must be taken to ensure that a SNMP engine is sending packets 1261 out over a transport using credentials that are legal for that engine 1262 to use on behalf of that user. Otherwise an engine that has multiple 1263 transports open might be "tricked" into sending a message through the 1264 wrong transport. 1266 A Security Model may have multiple sources from which to define the 1267 securityName and securityLevel. The use of a secure Transport Model 1268 does not imply that the securityName and securityLevel chosen by the 1269 Security Model represent the transport-authenticated identity or the 1270 transport-provided security services. The securityModel, 1271 securityName, and securityLevel parameters are a related set, and an 1272 administrator should understand how the specified securityModel 1273 selects the corresponding securityName and securityLevel. 1275 7.1. Coexistence, Security Parameters, and Access Control 1277 In the RFC3411 architecture, the Message Processing Model makes the 1278 decision about which Security Model to use. The architectural change 1279 described by this document does not alter that. 1281 The architecture change described by this document does however, 1282 allow SNMP to support two different approaches to security - message- 1283 driven security and transport-driven security. With message-driven 1284 security, SNMP provides its own security, and passes security 1285 parameters within the SNMP message; with transport-driven security, 1286 SNMP depends on an external entity to provide security during 1287 transport by "wrapping" the SNMP message. 1289 Using a non-transport-aware security model with a secure transport 1290 model is NOT RECOMMENDED, for the following reasons. 1292 Security models defined before the Transport Security Model (i.e., 1293 SNMPv1, SNMPv2c, and USM) do not support transport-based security, 1294 and only have access to the security parameters contained within the 1295 SNMP message. They do not know about the security parameters 1296 associated with a secure transport. As a result, the Access Control 1297 Subsystem bases its decisions on the security parameters extracted 1298 from the SNMP message, not on transport-based security parameters. 1300 Implications of combining older security models with secure transport 1301 models are known. The securityName used for access control decisions 1302 is based on the message-driven identity, which might be 1303 unauthenticated, not the transport-driven authenticated identity: 1305 o An SNMPv1 message will always be paired with an SNMPv1 Security 1306 Model (per RFC3584), regardless of the transport mapping or 1307 transport model used, and access controls will be based on the 1308 unauthenticated community name. 1310 o An SNMPv2c message will always be paired with an SNMPv2c Security 1311 Model (per RFC3584), regardless of the transport mapping or 1312 transport model used, and access controls will be based on the 1313 unauthenticated community name. 1315 o An SNMPv3 message will always be paired with the securityModel 1316 specified in the msgSecurityParameters field of the message (per 1317 RFC3412), regardless of the transport mapping or transport model 1318 used. If the SNMPv3 message specifies the User-based Security 1319 Model (USM), with noAuthNoPriv, then the access controls will be 1320 based on the unauthenticated USM user. 1322 o For outgoing messages, if a secure transport model is selected in 1323 combination with a security model that does not populate a 1324 tmStateReference, the secure transport model SHOULD detect the 1325 lack of a valid tmStateReference and fail. 1327 However, in times of network stress, a secure transport model may not 1328 work properly if its underlying security mechanisms (e.g., Network 1329 Time Protocol (NTP) or Authentication, Authorization, and Accounting 1330 (AAA) protocols or certificate authorities) are not reachable. The 1331 User-based Security Model was explicitly designed to not depend upon 1332 external network services, and provides its own security services. 1333 It is RECOMMENDED that operators provision authPriv USM as a fallback 1334 mechanism to supplement any security model or transport model that 1335 has external dependencies, so that secure SNMP communications can 1336 continue when the external network service is not available. 1338 8. IANA Considerations 1340 IANA is requested to create a new registry in the Simple Network 1341 Management Protocol (SNMP) Number Spaces. The new registry should be 1342 called "SNMP Transport Domains". This registry will contain ASCII 1343 strings of one to four characters to identify prefixes for 1344 corresponding SNMP transport domains. Each transport domain requires 1345 an OID assignment under snmpDomains [RFC2578] . Values are to be 1346 assigned via [RFC5226] "Specification Required". 1348 The registry should be populated with the following initial entries: 1350 Registry Name: SNMP Transport Domains 1351 Reference: [RFC2578] [RFC3417] [XXXX] 1352 Registration Procedures: Specification Required 1353 Each domain is assigned a MIB-defined OID under snmpDomains 1355 Prefix snmpDomains Reference 1356 ------- ----------------------------- --------- 1357 udp snmpUDPDomain RFC3417 1358 clns snmpCLNSDomain RFC3417 1359 cons snmpCONSDomain RFC3417 1360 ddp snmpDDPDomain RFC3417 1361 ipx snmpIPXDomain RFC3417 1362 prxy rfc1157Domain RFC3417 1364 -- NOTE to RFC editor: replace XXXX with actual RFC number 1365 -- for this document and remove this note 1367 9. Acknowledgments 1369 The Integrated Security for SNMP WG would like to thank the following 1370 people for their contributions to the process: 1372 The authors of submitted Security Model proposals: Chris Elliot, Wes 1373 Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David 1374 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1376 The members of the Protocol Evaluation Team: Uri Blumenthal, 1377 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1379 WG members who performed detailed reviews: Jeffrey Hutzelman, Bert 1380 Wijnen, Tom Petch, Wes Hardaker, and Dave Shield. 1382 10. References 1384 10.1. Normative References 1386 [RFC2119] Bradner, S., "Key words for 1387 use in RFCs to Indicate 1388 Requirement Levels", 1389 BCP 14, RFC 2119, 1390 March 1997. 1392 [RFC2578] McCloghrie, K., Ed., 1393 Perkins, D., Ed., and J. 1394 Schoenwaelder, Ed., 1395 "Structure of Management 1396 Information Version 2 1397 (SMIv2)", STD 58, RFC 2578, 1398 April 1999. 1400 [RFC3411] Harrington, D., Presuhn, 1401 R., and B. Wijnen, "An 1402 Architecture for Describing 1403 Simple Network Management 1404 Protocol (SNMP) Management 1405 Frameworks", STD 62, 1406 RFC 3411, December 2002. 1408 [RFC3412] Case, J., Harrington, D., 1409 Presuhn, R., and B. Wijnen, 1410 "Message Processing and 1411 Dispatching for the Simple 1412 Network Management Protocol 1413 (SNMP)", STD 62, RFC 3412, 1414 December 2002. 1416 [RFC3413] Levi, D., Meyer, P., and B. 1417 Stewart, "Simple Network 1418 Management Protocol (SNMP) 1419 Applications", STD 62, 1420 RFC 3413, December 2002. 1422 [RFC3414] Blumenthal, U. and B. 1423 Wijnen, "User-based 1424 Security Model (USM) for 1425 version 3 of the Simple 1426 Network Management Protocol 1427 (SNMPv3)", STD 62, 1428 RFC 3414, December 2002. 1430 [RFC3417] Presuhn, R., "Transport 1431 Mappings for the Simple 1432 Network Management Protocol 1433 (SNMP)", STD 62, RFC 3417, 1434 December 2002. 1436 10.2. Informative References 1438 [RFC2865] Rigney, C., Willens, S., 1439 Rubens, A., and W. Simpson, 1440 "Remote Authentication Dial 1441 In User Service (RADIUS)", 1442 RFC 2865, June 2000. 1444 [RFC3410] Case, J., Mundy, R., 1445 Partain, D., and B. 1447 Stewart, "Introduction and 1448 Applicability Statements 1449 for Internet-Standard 1450 Management Framework", 1451 RFC 3410, December 2002. 1453 [RFC3584] Frye, R., Levi, D., 1454 Routhier, S., and B. 1455 Wijnen, "Coexistence 1456 between Version 1, Version 1457 2, and Version 3 of the 1458 Internet-standard Network 1459 Management Framework", 1460 BCP 74, RFC 3584, 1461 August 2003. 1463 [RFC5246] Dierks, T. and E. Rescorla, 1464 "The Transport Layer 1465 Security (TLS) Protocol 1466 Version 1.2", RFC 5246, 1467 August 2008. 1469 [RFC4422] Melnikov, A. and K. 1470 Zeilenga, "Simple 1471 Authentication and Security 1472 Layer (SASL)", RFC 4422, 1473 June 2006. 1475 [RFC4251] Ylonen, T. and C. Lonvick, 1476 "The Secure Shell (SSH) 1477 Protocol Architecture", 1478 RFC 4251, January 2006. 1480 [RFC4741] Enns, R., "NETCONF 1481 Configuration Protocol", 1482 RFC 4741, December 2006. 1484 [RFC5226] Narten, T. and H. 1485 Alvestrand, "Guidelines for 1486 Writing an IANA 1487 Considerations Section in 1488 RFCs", BCP 26, RFC 5226, 1489 May 2008. 1491 [I-D.ietf-isms-transport-security-model] Harrington, D. and W. 1492 Hardaker, "Transport 1493 Security Model for SNMP", d 1494 raft-ietf-isms-transport- 1495 security-model-12 (work in 1496 progress), March 2009. 1498 [I-D.ietf-isms-secshell] Harrington, D., Salowey, 1499 J., and W. Hardaker, 1500 "Secure Shell Transport 1501 Model for SNMP", 1502 draft-ietf-isms-secshell-15 1503 (work in progress), 1504 March 2009. 1506 [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog 1507 Protocol", draft-ietf- 1508 syslog-protocol-23 (work in 1509 progress), September 2007. 1511 Appendix A. Why tmStateReference? 1513 This appendix considers why a cache-based approach was selected for 1514 passing parameters. 1516 There are four approaches that could be used for passing information 1517 between the Transport Model and a Security Model. 1519 1. one could define an ASI to supplement the existing ASIs, or 1521 2. one could add a header to encapsulate the SNMP message, 1523 3. one could utilize fields already defined in the existing SNMPv3 1524 message, or 1526 4. one could pass the information in an implementation-specific 1527 cache or via a MIB module. 1529 A.1. Define an Abstract Service Interface 1531 Abstract Service Interfaces (ASIs) are defined by a set of primitives 1532 that specify the services provided and the abstract data elements 1533 that are to be passed when the services are invoked. Defining 1534 additional ASIs to pass the security and transport information from 1535 the Transport Subsystem to Security Subsystem has the advantage of 1536 being consistent with existing RFC3411/3412 practice, and helps to 1537 ensure that any Transport Model proposals pass the necessary data, 1538 and do not cause side effects by creating model-specific dependencies 1539 between itself and other models or other subsystems other than those 1540 that are clearly defined by an ASI. 1542 A.2. Using an Encapsulating Header 1544 A header could encapsulate the SNMP message to pass necessary 1545 information from the Transport Model to the dispatcher and then to a 1546 Message Processing Model. The message header would be included in 1547 the wholeMessage ASI parameter, and would be removed by a 1548 corresponding Message Processing Model. This would imply the (one 1549 and only) messaging dispatcher would need to be modified to determine 1550 which SNMP message version was involved, and a new Message Processing 1551 Model would need to be developed that knew how to extract the header 1552 from the message and pass it to the Security Model. 1554 A.3. Modifying Existing Fields in an SNMP Message 1556 [RFC3412] defines the SNMPv3 message, which contains fields to pass 1557 security related parameters. The Transport Subsystem could use these 1558 fields in an SNMPv3 message, or comparable fields in other message 1559 formats to pass information between Transport Models in different 1560 SNMP engines, and to pass information between a Transport Model and a 1561 corresponding Message Processing Model. 1563 If the fields in an incoming SNMPv3 message are changed by the 1564 Transport Model before passing it to the Security Model, then the 1565 Transport Model will need to decode the ASN.1 message, modify the 1566 fields, and re-encode the message in ASN.1 before passing the message 1567 on to the message dispatcher or to the transport layer. This would 1568 require an intimate knowledge of the message format and message 1569 versions so the Transport Model knew which fields could be modified. 1570 This would seriously violate the modularity of the architecture. 1572 A.4. Using a Cache 1574 This document describes a cache, into which the Transport Model puts 1575 information about the security applied to an incoming message, and a 1576 Security Model can extract that information from the cache. Given 1577 that there might be multiple TM-security caches, a tmStateReference 1578 is passed as an extra parameter in the ASIs between the Transport 1579 Subsystem and the Security Subsystem, so the Security Model knows 1580 which cache of information to consult. 1582 This approach does create dependencies between a specific Transport 1583 Model and a corresponding specific Security Model. However, the 1584 approach of passing a model-independent reference to a model- 1585 dependent cache is consistent with the securityStateReference already 1586 being passed around in the RFC3411 ASIs. 1588 Authors' Addresses 1590 David Harrington 1591 Huawei Technologies (USA) 1592 1700 Alma Dr. Suite 100 1593 Plano, TX 75075 1594 USA 1596 Phone: +1 603 436 8634 1597 EMail: dharrington@huawei.com 1599 Juergen Schoenwaelder 1600 Jacobs University Bremen 1601 Campus Ring 1 1602 28725 Bremen 1603 Germany 1605 Phone: +49 421 200-3587 1606 EMail: j.schoenwaelder@iu-bremen.de