idnits 2.17.1 draft-ietf-isms-tmsm-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1663. 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 Copyright Line does not match the current year == Line 392 has weird spacing: '...patcher v ...' (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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 5, 2007) is 6290 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) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 13 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) International University Bremen 6 Intended status: Standards Track February 5, 2007 7 Expires: August 9, 2007 9 Transport Subsystem for the Simple Network Management Protocol (SNMP) 10 draft-ietf-isms-tmsm-06 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 9, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a Transport Subsystem, extending the Simple 44 Network Management Protocol (SNMP) architecture defined in RFC 3411. 45 This document defines a subsystem to contain Transport Models, 46 comparable to other subsystems in the RFC3411 architecture. As work 47 is being done to expand the transport to include secure transport 48 such as SSH and TLS, using a subsystem will enable consistent design 49 and modularity of such Transport Models. This document identifies 50 and describes some key aspects that need to be considered for any 51 Transport Model for SNMP. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. The Internet-Standard Management Framework . . . . . . . . 4 57 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 4 58 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8 61 3.1. Message Security Requirements . . . . . . . . . . . . . . 8 62 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8 63 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 9 64 3.2.1. Architectural Modularity Requirements . . . . . . . . 9 65 3.2.2. Access Control Requirements . . . . . . . . . . . . . 13 66 3.2.3. Security Parameter Passing Requirements . . . . . . . 14 67 3.2.4. Separation of Authentication and Authorization . . . . 15 68 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 16 69 3.3.1. Session Establishment Requirements . . . . . . . . . . 17 70 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 18 71 3.3.3. Message security versus session security . . . . . . . 18 72 4. Scenario Diagrams for the Transport Subsystem . . . . . . . . 19 73 4.1. Command Generator or Notification Originator . . . . . . . 19 74 4.2. Command Responder . . . . . . . . . . . . . . . . . . . . 21 75 5. Cached Information and References . . . . . . . . . . . . . . 22 76 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 23 77 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 24 78 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 24 79 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 24 80 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 25 81 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 26 82 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 27 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 89 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 31 90 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 31 91 Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 33 92 B.1. Define an Abstract Service Interface . . . . . . . . . . . 33 93 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 33 94 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 34 95 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 34 96 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 34 97 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 35 99 1. Introduction 101 This document defines a Transport Subsystem, extending the Simple 102 Network Management Protocol (SNMP) architecture defined in [RFC3411]. 103 This document identifies and describes some key aspects that need to 104 be considered for any Transport Model for SNMP. 106 1.1. The Internet-Standard Management Framework 108 For a detailed overview of the documents that describe the current 109 Internet-Standard Management Framework, please refer to section 7 of 110 RFC 3410 [RFC3410]. 112 1.2. Where this Extension Fits 114 It is expected that readers of this document will have read RFC3410 115 and RFC3411, and have a general understanding of the functionality 116 defined in RFCs 3412-3418. 118 The "Transport Subsystem" is an additional component for the SNMP 119 Engine depicted in RFC3411, section 3.1. 121 The following diagram depicts its place in the RFC3411 architecture.: 123 +-------------------------------------------------------------------+ 124 | SNMP entity | 125 | | 126 | +-------------------------------------------------------------+ | 127 | | SNMP engine (identified by snmpEngineID) | | 128 | | | | 129 | | +------------+ | | 130 | | | Transport | | | 131 | | | Subsystem | | | 132 | | +------------+ | | 133 | | | | 134 | | +------------+ +------------+ +-----------+ +-----------+ | | 135 | | | Dispatcher | | Message | | Security | | Access | | | 136 | | | | | Processing | | Subsystem | | Control | | | 137 | | | | | Subsystem | | | | Subsystem | | | 138 | | +------------+ +------------+ +-----------+ +-----------+ | | 139 | +-------------------------------------------------------------+ | 140 | | 141 | +-------------------------------------------------------------+ | 142 | | Application(s) | | 143 | | | | 144 | | +-------------+ +--------------+ +--------------+ | | 145 | | | Command | | Notification | | Proxy | | | 146 | | | Generator | | Receiver | | Forwarder | | | 147 | | +-------------+ +--------------+ +--------------+ | | 148 | | | | 149 | | +-------------+ +--------------+ +--------------+ | | 150 | | | Command | | Notification | | Other | | | 151 | | | Responder | | Originator | | | | | 152 | | +-------------+ +--------------+ +--------------+ | | 153 | +-------------------------------------------------------------+ | 154 | | 155 +-------------------------------------------------------------------+ 157 The transport mappings defined in RFC3417 do not provide lower-layer 158 security functionality, and thus do not provide transport-specific 159 security parameters. This document updates RFC3411 and RFC3417 by 160 defining an architectural extension and ASIs that transport mappings 161 (models) can use to pass transport-specific security parameters to 162 other subsystems, including transport-specific security parameters 163 translated into the transport-independent securityName and 164 securityLevel. 166 1.3. Conventions 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 The key words "must", "must not", "required", "shall", "shall not", 173 "should", "should not", "recommended", "may", and "optional" in this 174 document are not to be interpreted as described in RFC2119. They 175 will usually, but not always, be used in a context relating to 176 compatibility with the RFC3411 architecture or the subsystem defined 177 here, but which might have no impact on on-the-wire compatibility. 178 These terms are used as guidance for designers of proposed IETF 179 models to make the designs compatible with RFC3411 subsystems and 180 Abstract Service Interfaces (see section 3.2). Implementers are free 181 to implement differently. Some usages of these lowercase terms are 182 simply normal English usage. 184 2. Motivation 186 Just as there are multiple ways to secure one's home or business, in 187 a continuum of alternatives, there are multiple ways to secure a 188 network management protocol. Let's consider three general 189 approaches. 191 In the first approach, an individual could sit on his front porch 192 waiting for intruders. In the second approach, he could hire an 193 employee , schedule the employee, position the employee to guard what 194 he wants protected, hire a second guard to cover if the first gets 195 sick, and so on. In the third approach, he could hire a security 196 company, tell them what he wants protected, and they could hire 197 employees, train them, position the guards, schedule the guards, send 198 a replacement when a guard cannot make it, etc., thus providing the 199 desired security, with no significant effort on his part other than 200 identifying requirements and verifying the quality of the service 201 being provided. 203 The User-based Security Model (USM) as defined in [RFC3414] largely 204 uses the first approach - it provides its own security. It utilizes 205 existing mechanisms (e.g., SHA), but provides all the coordination. 206 USM provides for the authentication of a principal, message 207 encryption, data integrity checking, timeliness checking, etc. 209 USM was designed to be independent of other existing security 210 infrastructures. USM therefore requires a separate principal and key 211 management infrastructure. Operators have reported that deploying 212 another principal and key management infrastructure in order to use 213 SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use 214 external mechanisms to handle the distribution of keys for use by 215 USM. The more important issue is that operators wanted to leverage a 216 single user base that wasn't specific to SNMP. 218 A solution based on the second approach might use a USM-compliant 219 architecture, but combine the authentication mechanism with an 220 external mechanism, such as RADIUS [RFC2865], to provide the 221 authentication service. It might be possible to utilize an external 222 protocol to encrypt a message, to check timeliness, to check data 223 integrity, etc. It is difficult to cobble together a number of 224 subcontracted services and coordinate them however, because it is 225 difficult to build solid security bindings between the various 226 services, and potential for gaps in the security is significant. 228 A solution based on the third approach might utilize one or more 229 lower-layer security mechanisms to provide the message-oriented 230 security services required. These would include authentication of 231 the sender, encryption, timeliness checking, and data integrity 232 checking. There are a number of IETF standards available or in 233 development to address these problems through security layers at the 234 transport layer or application layer, among them TLS [RFC4366], SASL 235 [RFC4422], and SSH [RFC4251]. 237 From an operational perspective, it is highly desirable to use 238 security mechanisms that can unify the administrative security 239 management for SNMPv3, command line interfaces (CLIs) and other 240 management interfaces. The use of security services provided by 241 lower layers is the approach commonly used for the CLI, and is also 242 the approach being proposed for NETCONF [RFC4741]. 244 This document defines a Transport Subsystem extension to the RFC3411 245 architecture based on the third approach. This extension specifies 246 how other lower layer protocols with common security infrastructures 247 can be used underneath the SNMP protocol and the desired goal of 248 unified administrative security can be met. 250 This extension allows security to be provided by an external protocol 251 connected to the SNMP engine through an SNMP Transport Model 252 [RFC3417]. Such a Transport Model would then enable the use of 253 existing security mechanisms such as (TLS) [RFC4366] or SSH [RFC4251] 254 within the RFC3411 architecture. 256 There are a number of Internet security protocols and mechanisms that 257 are in wide spread use. Many of them try to provide a generic 258 infrastructure to be used by many different application layer 259 protocols. The motivation behind the Transport Subsystem is to 260 leverage these protocols where it seems useful. 262 There are a number of challenges to be addressed to map the security 263 provided by a secure transport into the SNMP architecture so that 264 SNMP continues to provide interoperability with existing 265 implementations. These challenges are described in detail in this 266 document. For some key issues, design choices are described that 267 might be made to provide a workable solution that meets operational 268 requirements and fits into the SNMP architecture defined in 269 [RFC3411]. 271 3. Requirements of a Transport Model 273 3.1. Message Security Requirements 275 Transport security protocols SHOULD provide protection against the 276 following message-oriented threats [RFC3411]: 278 1. modification of information 279 2. masquerade 280 3. message stream modification 281 4. disclosure 283 These threats are described in section 1.4 of [RFC3411]. It is not 284 required to protect against denial of service or traffic analysis, 285 but it should not make those threats significantly worse. 287 3.1.1. Security Protocol Requirements 289 There are a number of standard protocols that could be proposed as 290 possible solutions within the Transport Subsystem. Some factors 291 SHOULD be considered when selecting a protocol. 293 Using a protocol in a manner for which it was not designed has 294 numerous problems. The advertised security characteristics of a 295 protocol might depend on it being used as designed; when used in 296 other ways, it might not deliver the expected security 297 characteristics. It is recommended that any proposed model include a 298 description of the applicability of the Transport Model. 300 A Transport Model SHOULD require no modifications to the underlying 301 protocol. Modifying the protocol might change its security 302 characteristics in ways that would impact other existing usages. If 303 a change is necessary, the change SHOULD be an extension that has no 304 impact on the existing usages. Any Transport Model SHOULD include a 305 description of potential impact on other usages of the protocol. 307 Transport Models MUST be able to coexist with each other. 309 3.2. SNMP Requirements 311 3.2.1. Architectural Modularity Requirements 313 SNMP version 3 (SNMPv3) is based on a modular architecture (defined 314 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 315 standards over time, and to minimize side effects between subsystems 316 when changes are made. 318 The RFC3411 architecture includes a Security Subsystem for enabling 319 different methods of providing security services, a Message 320 Processing Subsystem permitting different message versions to be 321 handled by a single engine, Applications(s) to support different 322 types of application processors, and an Access Control Subsystem for 323 allowing multiple approaches to access control. The RFC3411 324 architecture does not include a subsystem for Transport Models, 325 despite the fact there are multiple transport mappings already 326 defined for SNMP. This document addresses the need for a Transport 327 Subsystem compatible with the RFC3411 architecture. As work is being 328 done to expand the transport to include secure transport such as SSH 329 and TLS, using a subsystem will enable consistent design and 330 modularity of such Transport Models. 332 The design of this Transport Subsystem accepts the goals of the 333 RFC3411 architecture defined in section 1.5 of [RFC3411]. This 334 Transport Subsystem uses a modular design that will permit Transport 335 Models to be advanced through the standards process independently of 336 other Transport Models, and independent of other modular SNMP 337 components as much as possible. 339 Parameters have been added to the ASIs to pass model-independent 340 transport address information. 342 IETF standards typically require one mandatory to implement solution, 343 with the capability of adding new mechanisms in the future. Part of 344 the motivation of developing Transport Models is to develop support 345 for secure transport protocols, such as a Transport Model that 346 utilizes the Secure Shell protocol. Any Transport Model SHOULD 347 define one minimum-compliance security mechanism, such as 348 certificates, to ensure a basic level of interoperability, but should 349 also be able to support additional existing and new mechanisms. 351 The Transport Subsystem permits multiple transport protocols to be 352 "plugged into" the RFC3411 architecture, supported by corresponding 353 Transport Models, including models that are security-aware. 355 The RFC3411 architecture and the Security Subsystem assume that a 356 Security Model is called by a Message Processing Model and will 357 perform multiple security functions within the Security Subsystem. A 358 Transport Model that supports a secure transport protocol might 359 perform similar security functions within the Transport Subsystem. A 360 Transport Model might perform the translation of transport security 361 parameters to/from security-model-independent parameters. 363 To accommodate this, an implementation-specific cache of transport- 364 specific information will be described (not shown), and the data 365 flows between the Transport Subsystem and the Transport Dispatch, 366 between the Message Dispatch and the Message Processing Subsystem, 367 and between the Message Processing Subsystem and the Security 368 Subsystem will be extended to pass security-model-independent values. 369 New Security Models may also be defined that understand how to work 370 with the modified ASIs and the cache. One such Security Mode, the 371 Transport Security Model, is defined in 373 The following diagram depicts the SNMPv3 architecture including the 374 new Transport Subsystem defined in this document, and a new Transport 375 Security Model defined in [I-D.ietf-isms-transport-security-model]. 377 +------------------------------+ 378 | Network | 379 +------------------------------+ 380 ^ ^ ^ 381 | | | 382 v v v 383 +-------------------------------------------------------------------+ 384 | +--------------------------------------------------+ | 385 | | Transport Subsystem | | 386 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 387 | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | 388 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 389 | +--------------------------------------------------+ | 390 | ^ | 391 | | | 392 | Dispatcher v | 393 | +-------------------+ +---------------------+ +----------------+ | 394 | | Transport | | Message Processing | | Security | | 395 | | Dispatch | | Subsystem | | Subsystem | | 396 | | | | +------------+ | | +------------+ | | 397 | | | | +->| v1MP |<--->| | USM | | | 398 | | | | | +------------+ | | +------------+ | | 399 | | | | | +------------+ | | +------------+ | | 400 | | | | +->| v2cMP |<--->| | Transport | | | 401 | | Message | | | +------------+ | | | Security | | | 402 | | Dispatch <--------->| +------------+ | | | Model | | | 403 | | | | +->| v3MP |<--->| +------------+ | | 404 | | | | | +------------+ | | +------------+ | | 405 | | PDU Dispatch | | | +------------+ | | | Other | | | 406 | +-------------------+ | +->| otherMP |<--->| | Model(s) | | | 407 | ^ | +------------+ | | +------------+ | | 408 | | +---------------------+ +----------------+ | 409 | v | 410 | +-------+-------------------------+---------------+ | 411 | ^ ^ ^ | 412 | | | | | 413 | v v v | 414 | +-------------+ +---------+ +--------------+ +-------------+ | 415 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 416 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 417 | | application | | | | applications | | application | | 418 | +-------------+ +---------+ +--------------+ +-------------+ | 419 | ^ ^ | 420 | | | | 421 | v v | 422 | +----------------------------------------------+ | 423 | | MIB instrumentation | SNMP entity | 424 +-------------------------------------------------------------------+ 426 3.2.1.1. Processing Differences between USM and Secure Transport 428 USM and secure transports differ is the processing order and 429 responsibilities within the RFC3411 architecture. While the steps 430 are the same, they occur in a different order, and may be done by 431 different subsystems. The following lists illustrate the difference 432 in the flow and the responsibility for different processing steps for 433 incoming messages when using USM and when using a secure transport. 434 (Note that these lists are simplified for illustrative purposes, and 435 do not represent all details of processing. Transport Models must 436 provide the detailed elements of procedure.) 438 With USM and other Security Models, security processing starts when 439 the Message Processing Model decodes portions of the ASN.1 message to 440 extract an opaque block of security parameters and header parameters 441 that identify which Security Model should process the message to 442 perform authentication, decryption, timeliness checking, integrity 443 checking, and translation of parameters to model-independent 444 parameters. A secure transport performs those security functions on 445 the message, before the ASN.1 is decoded. 447 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 448 are the same for USM and a secure transport. 450 3.2.1.1.1. USM and the RFC3411 Architecture 452 1) decode the ASN.1 header (Message Processing Model) 453 2) determine the SNMP Security Model and parameters (Message 454 Processing Model) 455 3) verify securityLevel. [Security Model] 456 4) translate parameters to model-independent parameters (Security 457 Model) 458 5) authenticate and decrypt message. [Security Model] 459 6) determine the pduType in the decrypted portions (Message 460 Processing Model), and 461 7) pass on the decrypted portions with model-independent parameters. 463 3.2.1.2. Transport Subsystem and the RFC3411 Architecture 465 1) authenticate and decrypt message. [Transport Model] 466 2) translate parameters to model-independent parameters (Transport 467 Model) 468 3) decode the ASN.1 header (Message Processing Model) 469 4) determine the SNMP Security Model and parameters (Message 470 Processing Model) 472 5) verify securityLevel [Security Model] 473 6) determine the pduType in the decrypted portions (Message 474 Processing Model), and 475 7) pass on the decrypted portions with model-independent security 476 parameters 478 If a message is secured using a secure transport layer, then the 479 Transport Model should provide the translation from the authenticated 480 identity (e.g., an SSH user name) to the securityName in step 3. 482 3.2.1.3. Passing Information between Engines 484 A secure Transport Model will establish an authenticated and/or 485 encrypted tunnel between the Transport Models of two SNMP engines. 486 After a transport layer tunnel is established, then SNMP messages can 487 be sent through the tunnel from one SNMP engine to the other SNMP 488 engine. Transport Models MAY support sending multiple SNMP messages 489 through the same tunnel. 491 3.2.2. Access Control Requirements 493 RFC3411 made some design decisions related to the support of an 494 Access Control Subsystem. These include a securityName and 495 securityLevel mapping, the separation of Authentication and 496 Authorization, and the passing of model-independent security 497 parameters. 499 3.2.2.1. securityName and securityLevel Mapping 501 For SNMP access control to function properly, Security Models MUST 502 establish a securityLevel and a securityName, which is the security- 503 model-independent identifier for a principal. The Message Processing 504 Subsystem relies on a Security Model, such as USM, to play a role in 505 security that goes beyond protecting the message - it provides a 506 mapping between the security-model-specific principal to a security- 507 model independent securityName which can be used for subsequent 508 processing, such as for access control. 510 The securityName MUST be mapped from the mechanism-specific 511 authenticated identity, and this mapping must be done for incoming 512 messages before the Security Model passes securityName to the Message 513 Processing Model via the processIncoming ASI. This translation from 514 a mechanism-specific authenticated identity to a securityName might 515 be done by the Transport Model, and the securityName is then provided 516 to the Security Model via the tmStateReference to be passed to the 517 Message Processing Model. 519 If the type of authentication provided by the transport layer (e.g., 520 TLS) is considered adequate to secure and/or encrypt the message, but 521 inadequate to provide the desired granularity of access control 522 (e.g., user-based), then a second authentication (e.g., one provided 523 via a RADIUS server) MAY be used to provide the authentication 524 identity which is mapped to the securityName. This approach would 525 require a good analysis of the potential for man-in-the-middle 526 attacks or masquerade possibilities. 528 3.2.3. Security Parameter Passing Requirements 530 RFC3411 section 4 describes abstract data flows between the 531 subsystems, models and applications within the architecture. 532 Abstract Service Interfaces describe the flow of data, passing model- 533 independent information between subsystems within an engine. The 534 RFC3411 architecture has no ASI parameters for passing security 535 information between the Transport Subsystem and the dispatcher, or 536 between the dispatcher and the Message Processing Model. This 537 document defines or modifies ASIs for this purpose. 539 The security parameters include a model-independent identifier of the 540 security "principal" (the securityName), the Security Model used to 541 perform the authentication, and which authentication and privacy 542 services were (should be) applied to the message (securityLevel). 544 A Message Processing Model might unpack SNMP-specific security 545 parameters from an incoming message before calling a specific 546 Security Model to authenticate and decrypt an incoming message, 547 perform integrity checking, and translate security-model-specific 548 parameters into model-independent parameters. When using a secure 549 Transport Model, security parameters might be provided through means 550 other than carrying them in the SNMP message; the parameters for 551 incoming messages might be extracted from the transport layer by the 552 Transport Model before the message is passed to the Message 553 Processing Subsystem. 555 This document describes a cache mechanism (see Section 5), into which 556 the Transport Model puts information about the transport and security 557 parameters applied to a transport connection or an incoming message, 558 and a Security Model may extract that information from the cache. A 559 tmStateReference is passed as an extra parameter in the ASIs of the 560 Transport Subsystem and the Message Processing and Security 561 Subsystems, to identify the relevant cache. This approach of passing 562 a model-independent reference is consistent with the 563 securityStateReference cache already being passed around in the 564 RFC3411 ASIs. 566 For outgoing messages, even when a secure Transport Model will 567 provide the security services, a Message Processing Model might have 568 a Security Model actually create the message from its component 569 parts. Whether there are any security services provided by the 570 Security Model for an outgoing message is security-model-dependent. 571 For incoming messages, even when a secure Transport Model provides 572 security services, a Security Model might provide some security 573 functionality that can only be provided after the message version or 574 other parameters are extracted from the message. 576 3.2.4. Separation of Authentication and Authorization 578 The RFC3411 architecture defines a separation of authentication and 579 authorization (access control), and a Transport Model that provides 580 security services should take care to not violate this separation. A 581 Transport Model must not specify how the securityModel and 582 securityName could be dynamically mapped to an access control 583 mechanism, such as a VACM-style groupName. 585 The RECOMMENDED approach is to pass the model-independent security 586 parameters via the isAccessAllowed ASI, and perform the mapping from 587 the model-independent security parameters to an access-control-model- 588 dependent policy within the Access Control Model. The 589 isAccessAllowed ASI is used for passing the securityModel, 590 securityName, and securityLevel parameters that are independent of 591 any specific security model and any specific access control model to 592 the Access Control Subsystem. 594 The mapping of (securityModel, securityName, securityLevel) to an 595 access-control-model-specific policy should be handled within a 596 specific access control model. This mapping should not be done in 597 the Transport or Security Subsystems, to be consistent with the 598 modularity of the RFC3411 architecture. This separation was a 599 deliberate decision of the SNMPv3 WG, to allow support for 600 authentication protocols which did not provide authorization (access 601 control) capabilities, and to support authorization schemes, such as 602 VACM, that do not perform their own authentication. 604 The View-based Access Control Model uses the securityModel and the 605 securityName as inputs to check for access rights. It determines the 606 groupName as a function of securityModel and securityName. Providing 607 a binding outside the Access Control Subsystem might create 608 dependencies that could make it harder to develop alternate models of 609 access control, such as one built on UNIX groups or Windows domains. 611 To provide support for protocols which simultaneously send 612 information for authentication and authorization (access control), 613 such as RADIUS [RFC2865], access-control-model-specific information 614 might be cached or otherwise made available to the Access Control 615 Subsystem, e.g., via a MIB table similar to the 616 vacmSecurityToGroupTable, so the Access Control Subsystem can create 617 an appropriate binding between the access-control-model-independent 618 securityModel and securityName and an access-control-model-specific 619 policy. This would be highly undesirable, however, if it creates a 620 dependency between a Transport Model or a Security Model and an 621 Access Control Model. 623 3.3. Session Requirements 625 Some secure transports might have a notion of sessions, while other 626 secure transports might provide channels or other session-like 627 mechanism. Throughout this document, the term session is used in a 628 broad sense to cover sessions, channels, and session-like mechanisms. 629 Session refers to an association between two SNMP engines that 630 permits the transmission of one or more SNMP messages within the 631 lifetime of the session. How the session is actually established, 632 opened, closed, or maintained is specific to a particular Transport 633 Model. 635 Sessions are not part of the SNMP architecture defined in [RFC3411], 636 but are considered desirable because the cost of authentication can 637 be amortized over potentially many transactions. 639 The architecture defined in [RFC3411] does not include a session 640 selector in the Abstract Service Interfaces, and neither is that done 641 for the Transport Subsystem, so an SNMP application has no mechanism 642 to select a session using the ASIs except by passing a unique 643 combination of transportDomain, transportAddress, securityName, 644 securityModel, and securityLevel. Implementers, of course, might 645 provide non-standard mechanisms to select sessions. The 646 transportDomain and transportAddress identify the transport 647 connection to a remote network node; the securityName identifies 648 which security principal to communicate with at that address (e.g., 649 different NMS applications), and the securityModel and securityLevel 650 might permit selection of different sets of security properties for 651 different purposes (e.g., encrypted SETs vs. non-encrypted GETs). 653 All Transport Models should discuss the impact of sessions on SNMP 654 usage, including how to establish/open a transport session (i.e., how 655 it maps to the concepts of session-like mechanisms of the underlying 656 protocol), how to behave when a session cannot be established, how to 657 close a session properly, how to behave when a session is closed 658 improperly, the session security properties, session establishment 659 overhead, and session maintenance overhead. 661 To reduce redundancy, this document describes aspects that are 662 expected to be common to all Transport Model sessions. 664 3.3.1. Session Establishment Requirements 666 SNMP applications must provide the transportDomain, transportAddress, 667 securityName, securityModel, and securityLevel to be used for a 668 session. 670 SNMP Applications might have no knowledge of whether the session that 671 will be used to carry commands was initially established as a 672 notification session, or a request-response session, and SHOULD NOT 673 make any assumptions based on knowing the direction of the session. 674 If an administrator or Transport Model designer wants to 675 differentiate a session established for different purposes, such as a 676 notification session versus a request-response session, the 677 application can use different securityNames or transport addresses 678 (e.g., port 161 vs. port 162) for different purposes. 680 An SNMP engine containing an application that initiates 681 communication, e.g., a Command Generator or Notification Originator, 682 must be able to attempt to establish a session for delivery if a 683 session does not yet exist. If a session cannot be established then 684 the message is discarded. 686 Sessions are usually established by the Transport Model when no 687 appropriate session is found for an outgoing message, but sessions 688 might be established in advance to support features such as 689 notifications. How sessions are established in advance is beyond the 690 scope of this document. 692 Sessions are initiated by notification originators when there is no 693 currently established connection that can be used to send the 694 notification. For a client-server security protocol, this might 695 require provisioning authentication credentials on the agent, either 696 statically or dynamically, so the client/agent can successfully 697 authenticate to a notification receiver. 699 A Transport Model must be able to determine whether a session does or 700 does not exist, and must be able to determine which session has the 701 appropriate security characteristics (transportDomain, 702 transportAddress, securityName, securityModel, and securityLevel) for 703 an outgoing message. 705 A Transport Model implementation MAY reuse an already established 706 session with the appropriate transportDomain, transportAddress, 707 securityName, securityModel, and securityLevel characteristics for 708 delivery of a message containing a different pduType than originally 709 caused the session to be created. For example, an implementation 710 that has an existing session originally established to receive a 711 request MAY use that session to send an outgoing notification, and 712 MAY use a session that was originally established to send a 713 notification to send a request. Responses SHOULD be returned using 714 the same session that carried the corresponding request message. 715 Reuse of sessions is not required for conformance. 717 If a session can be reused for a different pduType, but a receiver is 718 not prepared to accept different pduTypes over the same session, then 719 the message MAY be dropped by the receiver. 721 3.3.2. Session Maintenance Requirements 723 A Transport Model can tear down sessions as needed. It might be 724 necessary for some implementations to tear down sessions as the 725 result of resource constraints, for example. 727 The decision to tear down a session is implementation-dependent. 728 While it is possible for an implementation to automatically tear down 729 each session once an operation has completed, this is not recommended 730 for anticipated performance reasons. How an implementation 731 determines that an operation has completed, including all potential 732 error paths, is implementation-dependent. 734 The elements of procedure describe when cached information can be 735 discarded, in some circumstances, and the timing of cache cleanup 736 might have security implications, but cache memory management is an 737 implementation issue. 739 If a Transport Model defines MIB module objects to maintain session 740 state information, then the Transport Model MUST define what SHOULD 741 happen to the objects when a related session is torn down, since this 742 will impact interoperability of the MIB module. 744 3.3.3. Message security versus session security 746 A Transport Model session is associated with state information that 747 is maintained for its lifetime. This state information allows for 748 the application of various security services to multiple messages. 749 Cryptographic keys established at the beginning of the session SHOULD 750 be used to provide authentication, integrity checking, and encryption 751 services for data that is communicated during the session. The 752 cryptographic protocols used to establish keys for a Transport Model 753 session SHOULD ensure that fresh new session keys are generated for 754 each session. In addition sequence information might be maintained 755 in the session which can be used to prevent the replay and reordering 756 of messages within a session. If each session uses new keys, then a 757 cross-session replay attack will be unsuccessful; that is, an 758 attacker cannot successfully replay on one session a message he 759 observed from another session. A good security protocol will also 760 protect against replay attacks _within_ a session; that is, an 761 attacker cannot successfully replay a message observed earlier in the 762 same session. 764 A Transport Model session will have a single transportDomain, 765 transportAddress, securityModel, securityName and securityLevel 766 associated with it. If an exchange between communicating engines 767 requires a different securityLevel or is on behalf of a different 768 securityName, or uses a different securityModel, then another session 769 would be needed. An immediate consequence of this is that 770 implementations SHOULD be able to maintain some reasonable number of 771 concurrent sessions. 773 For Transport Models, securityName should be specified during session 774 setup, and associated with the session identifier. 776 SNMPv3 was designed to support multiple levels of security, 777 selectable on a per-message basis by an SNMP application, because, 778 for example, there is not much value in using encryption for a 779 Commander Generator to poll for potentially non-sensitive performance 780 data on thousands of interfaces every ten minutes; the encryption 781 might add significant overhead to processing of the messages. 783 Some Transport Models might support only specific authentication and 784 encryption services, such as requiring all messages to be carried 785 using both authentication and encryption, regardless of the security 786 level requested by an SNMP application. A Transport Model may 787 upgrade the requested security level, i.e. noAuthNoPriv and 788 authNoPriv MAY be sent over an authenticated and encrypted session. 790 4. Scenario Diagrams for the Transport Subsystem 792 RFC3411 section 4.6 provides scenario diagrams to illustrate how an 793 outgoing message is created, and how an incoming message is 794 processed. Both diagrams are incomplete, however. In section 4.6.1, 795 the diagram doesn't show an ASI for sending an SNMP request to the 796 network or for receiving an SNMP response message from the network. 797 In section 4.6.2, the diagram doesn't show the ASIs to receive an 798 SNMP message from the network, or to send an SNMP message to the 799 network. 801 4.1. Command Generator or Notification Originator 803 This diagram from RFC3411 4.6.1 shows how a Command Generator or 804 Notification Originator application [RFC3413] requests that a PDU be 805 sent, and how the response is returned (asynchronously) to that 806 application. 808 This document defines a sendMessage ASI to send SNMP messages to the 809 network, and a receiveMessage ASI to receive SNMP messages from the 810 network. 812 Command Dispatcher Message Security 813 Generator | Processing Model 814 | | Model | 815 | sendPdu | | | 816 |------------------->| | | 817 | | prepareOutgoingMessage | | 818 : |----------------------->| | 819 : | | generateRequestMsg | 820 : | |-------------------->| 821 : | | | 822 : | |<--------------------| 823 : | | | 824 : |<-----------------------| | 825 : | | | 826 : |------------------+ | | 827 : | Send SNMP | | | 828 : | Request Message | | | 829 : | to Network | | | 830 : | v | | 831 : : : : : 832 : : : : : 833 : : : : : 834 : | | | | 835 : | Receive SNMP | | | 836 : | Response Message | | | 837 : | from Network | | | 838 : |<-----------------+ | | 839 : | | | 840 : | prepareDataElements | | 841 : |----------------------->| | 842 : | | processIncomingMsg | 843 : | |-------------------->| 844 : | | | 845 : | |<--------------------| 846 : | | | 847 : |<-----------------------| | 848 | processResponsePdu | | | 849 |<-------------------| | | 850 | | | | 852 4.2. Command Responder 854 This diagram shows how a Command Responder or Notification Receiver 855 application registers for handling a pduType, how a PDU is dispatched 856 to the application after an SNMP message is received, and how the 857 Response is (asynchronously) sent back to the network. 859 This document defines the sendMessage and receiveMessage ASIs for 860 this purpose. 862 Command Dispatcher Message Security 863 Responder | Processing Model 864 | | Model | 865 | | | | 866 | registerContextEngineID | | | 867 |------------------------>| | | 868 |<------------------------| | | | 869 | | Receive SNMP | | | 870 : | Message | | | 871 : | from Network | | | 872 : |<-------------+ | | 873 : | | | 874 : |prepareDataElements | | 875 : |------------------->| | 876 : | | processIncomingMsg | 877 : | |------------------->| 878 : | | | 879 : | |<-------------------| 880 : | | | 881 : |<-------------------| | 882 | processPdu | | | 883 |<------------------------| | | 884 | | | | 885 : : : : 886 : : : : 887 | returnResponsePdu | | | 888 |------------------------>| | | 889 : | prepareResponseMsg | | 890 : |------------------->| | 891 : | |generateResponseMsg | 892 : | |------------------->| 893 : | | | 894 : | |<-------------------| 895 : | | | 896 : |<-------------------| | 897 : | | | 898 : |--------------+ | | 899 : | Send SNMP | | | 900 : | Message | | | 901 : | to Network | | | 902 : | v | | 904 5. Cached Information and References 906 The RFC3411 architecture uses caches to store dynamic model-specific 907 information, and uses references in the ASIs to indicate in a model- 908 independent manner which cached information flows between subsystems. 910 There are two levels of state that might need to be maintained: the 911 security state in a request-response pair, and potentially long-term 912 state relating to transport and security. 914 This state is maintained in caches. To simplify the elements of 915 procedure, the release of state information is not always explicitly 916 specified. As a general rule, if state information is available when 917 a message being processed gets discarded, the state related to that 918 message should also be discarded, and if state information is 919 available when a relationship between engines is severed, such as the 920 closing of a transport session, the state information for that 921 relationship might also be discarded. 923 This document differentiates the tmStateReference from the 924 securityStateReference. This document does not specify an 925 implementation strategy, only an abstract description of the data 926 that flows between subsystems. An implementation might use one cache 927 and one reference to serve both functions, but an implementer must be 928 aware of the cache-release issues to prevent the cache from being 929 released before a security or Transport Model has had an opportunity 930 to extract the information it needs. 932 5.1. securityStateReference 934 From RFC3411: "For each message received, the Security Model caches 935 the state information such that a Response message can be generated 936 using the same security information, even if the Local Configuration 937 Datastore is altered between the time of the incoming request and the 938 outgoing response." To enable this, an abstract 939 securityStateReference data element, defined in RFC3411 section 940 A.1.5, is passed from the Security Model to the Message Processing 941 Model. 943 The information saved should include the model-independent parameters 944 (transportDomain, transportAddress, securityName, securityModel, and 945 securityLevel), related security parameters, and other information 946 needed to match the response with the request. The related security 947 parameters may include transport-specific security information. 949 The Message Processing Model has the responsibility for explicitly 950 releasing the securityStateReference when such data is no longer 951 needed. The securityStateReference cached data may be implicitly 952 released via the generation of a response, or explicitly released by 953 using the stateRelease ASI, as defined in RFC 3411 section 4.5.1." 955 If the Transport Model connection is closed between the time a 956 Request is received and a Response message is being prepared, then 957 the Response message MAY be discarded. 959 5.2. tmStateReference 961 For each message or transport session, information about the message 962 security is stored in a cache, which may include model- and 963 mechanism-specific parameters. The tmStateReference is passed 964 between subsystems to provide a handle for the cache. A Transport 965 Model may store transport-specific parameters in the cache for 966 subsequent usage. Since the contents of a cache are meaningful only 967 within an implementation, and not on-the-wire, the format of the 968 cache is implementation-specific. 970 The state referenced by tmStateReference might be saved in a Local 971 Configuration Datastore (LCD) to make it available across multiple 972 messages, as compared to securityStateReference which is designed to 973 be saved only for the life of a request-response pair of messages. 974 It is expected that an LCD will allow lookup based on the combination 975 of transportDomain, transportAddress, securityName, securityModel, 976 and securityLevel, and that the cache contain these values to 977 reference entries in the LCD. 979 6. Abstract Service Interfaces 981 Abstract service interfaces have been defined by RFC 3411 to describe 982 the conceptual data flows between the various subsystems within an 983 SNMP entity, and to help keep the subsystems independent of each 984 other except for the common parameters. 986 This document follows the example of RFC3411 regarding the release of 987 state information, and regarding error indications. 989 1) The release of state information is not always explicitly 990 specified in a transport model. As a general rule, if state 991 information is available when a message gets discarded, the message- 992 state information should also be released, and if state information 993 is available when a session is closed, the session state information 994 should also be released. 996 2) An error indication in statusInformation may include an OID and 997 value for an incremented counter and a value for securityLevel, and 998 values for contextEngineID and contextName for the counter, and the 999 securityStateReference if the information is available at the point 1000 where the error is detected. 1002 6.1. sendMessage ASI 1004 The sendMessage ASI is used to pass a message from the Dispatcher to 1005 the appropriate Transport Model for sending. 1007 If present and valid, the tmStateReference refers to a cache 1008 containing transport-model-specific parameters for the transport and 1009 transport security. How the information in the cache is used is 1010 transport-model-dependent and implementation-dependent. How a 1011 tmStateReference is determined to be present and valid is 1012 implementation-dependent. 1014 This may sound underspecified, but keep in mind that a transport 1015 model might be something like SNMP over UDP over IPv6, where no 1016 security is provided, so it might have no mechanisms for utilizing a 1017 securityName and securityLevel. 1019 statusInformation = 1020 sendMessage( 1021 IN destTransportDomain -- transport domain to be used 1022 IN destTransportAddress -- transport address to be used 1023 IN outgoingMessage -- the message to send 1024 IN outgoingMessageLength -- its length 1025 IN tmStateReference -- reference to transport state 1026 ) 1028 6.2. Other Outgoing ASIs 1030 A tmStateReference parameter has been added to the 1031 prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg 1032 ASIs as an OUT parameter. 1034 statusInformation = -- success or errorIndication 1035 prepareOutgoingMessage( 1036 IN transportDomain -- transport domain to be used 1037 IN transportAddress -- transport address to be used 1038 IN messageProcessingModel -- typically, SNMP version 1039 IN securityModel -- Security Model to use 1040 IN securityName -- on behalf of this principal 1041 IN securityLevel -- Level of Security requested 1042 IN contextEngineID -- data from/at this entity 1043 IN contextName -- data from/in this context 1044 IN pduVersion -- the version of the PDU 1045 IN PDU -- SNMP Protocol Data Unit 1046 IN expectResponse -- TRUE or FALSE 1047 IN sendPduHandle -- the handle for matching 1048 incoming responses 1049 OUT destTransportDomain -- destination transport domain 1050 OUT destTransportAddress -- destination transport address 1051 OUT outgoingMessage -- the message to send 1052 OUT outgoingMessageLength -- its length 1053 OUT tmStateReference -- (NEW) reference to transport state 1054 ) 1056 The tmStateReference parameter of generateRequestMsg or 1057 generateResponseMsg is passed in the return parameters of the 1058 Security Subsystem to the Message Processing Subsystem. If a cache 1059 exists for a session identifiable from transportDomain, 1060 transportAddress, securityModel, securityName, and securityLevel, 1061 then an appropriate Security Model might create a tmStateReference to 1062 the cache and pass that as an OUT parameter. 1064 If one does not exist, the Security Model might create a cache 1065 referenced by tmStateReference. This information might include 1066 transportDomain, transportAddress, the securityModel, the 1067 securityLevel, and the securityName, plus any model or mechanism- 1068 specific details. The contents of the cache may be incomplete until 1069 the Transport Model has established a session. What information is 1070 passed, and how this information is determined, is implementation and 1071 security-model-specific. 1073 The prepareOutgoingMessage ASI passes tmStateReference from the 1074 Message Processing Subsystem to the dispatcher. How or if the 1075 Message Processing Subsystem modifies or utilizes the contents of the 1076 cache is message-processing-model-specific. 1078 This may sound underspecified, but keep in mind that a message 1079 processing model might have access to all the information from the 1080 cache and from the message, and have no need to call a Security Model 1081 to do any processing; an application might choose a Security Model 1082 such as USM to authenticate and secure the SNMP message, but also 1083 utilize a secure transport such as that provided by the SSH Transport 1084 Model to send the message to its destination. 1086 6.3. The receiveMessage ASI 1088 If one does not exist, the Transport Model might create a cache 1089 referenced by tmStateReference. If present, this information might 1090 include transportDomain, transportAddress, securityLevel, and 1091 securityName, plus model or mechanism-specific details. How this 1092 information is determined is implementation and transport-model- 1093 specific. 1095 This may sound underspecified, but keep in mind that a transport 1096 model might be something like SNMP over UDP over IPv6, where no 1097 security is provided, so it might have no mechanisms for determining 1098 a securityName and securityLevel. 1100 The Transport Model does not know the securityModel for an incoming 1101 message; this will be determined by the Message Processing Model in a 1102 message-processing-model-dependent manner. 1104 The receiveMessage ASI is used to pass a message from the Transport 1105 Subsystem to the Dispatcher. 1107 statusInformation = 1108 receiveMessage( 1109 IN transportDomain -- origin transport domain 1110 IN transportAddress -- origin transport address 1111 IN incomingMessage -- the message received 1112 IN incomingMessageLength -- its length 1113 IN tmStateReference -- reference to transport state 1114 ) 1116 6.4. Other Incoming ASIs 1118 To support the Transport Subsystem, the tmStateReference is added to 1119 the prepareDataElements ASI (from the Dispatcher to the Message 1120 Processing Subsystem), and to the processIncomingMsg ASI (from the 1121 Message Processing Subsystem to the Security Model Subsystem). How 1122 or if a Message Processing Model or Security Model uses 1123 tmStateReference is message-processing-model-dependent and security- 1124 model-dependent. 1126 result = -- SUCCESS or errorIndication 1127 prepareDataElements( 1128 IN transportDomain -- origin transport domain 1129 IN transportAddress -- origin transport address 1130 IN wholeMsg -- as received from the network 1131 IN wholeMsgLength -- as received from the network 1132 IN tmStateReference -- (NEW) from the Transport Model 1133 OUT messageProcessingModel -- typically, SNMP version 1134 OUT securityModel -- Security Model to use 1135 OUT securityName -- on behalf of this principal 1136 OUT securityLevel -- Level of Security requested 1137 OUT contextEngineID -- data from/at this entity 1138 OUT contextName -- data from/in this context 1139 OUT pduVersion -- the version of the PDU 1140 OUT PDU -- SNMP Protocol Data Unit 1141 OUT pduType -- SNMP PDU type 1142 OUT sendPduHandle -- handle for matched request 1143 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1144 OUT statusInformation -- success or errorIndication 1145 -- error counter OID/value if error 1146 OUT stateReference -- reference to state information 1147 -- to be used for possible Response 1148 ) 1149 statusInformation = -- errorIndication or success 1150 -- error counter OID/value if error 1151 processIncomingMsg( 1152 IN messageProcessingModel -- typically, SNMP version 1153 IN maxMessageSize -- of the sending SNMP entity 1154 IN securityParameters -- for the received message 1155 IN securityModel -- for the received message 1156 IN securityLevel -- Level of Security 1157 IN wholeMsg -- as received on the wire 1158 IN wholeMsgLength -- length as received on the wire 1159 IN tmStateReference -- (NEW) from the Transport Model 1160 OUT securityEngineID -- authoritative SNMP entity 1161 OUT securityName -- identification of the principal 1162 OUT scopedPDU, -- message (plaintext) payload 1163 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 1164 OUT securityStateReference -- reference to security state 1165 ) -- information, needed for response 1167 The tmStateReference parameter of prepareDataElements is passed from 1168 the dispatcher to the Message Processing Subsystem. How or if the 1169 Message Processing Subsystem modifies or utilizes the contents of the 1170 cache is message-processing-model-specific. 1172 The processIncomingMessage ASI passes tmStateReference from the 1173 Message Processing Subsystem to the Security Subsystem. 1175 If tmStateReference is present and valid, an appropriate Security 1176 Model might utilize the information in the cache. How or if the 1177 Security Subsystem utilizes the information in the cache is security- 1178 model-specific. 1180 This may sound underspecified, but keep in mind that a message 1181 processing model might have access to all the information from the 1182 cache and from the message, and have no need to call a Security Model 1183 to do any processing. The Message Processing Model might determine 1184 that the USM Security Model is specified in an SNMPv3 message header; 1185 the USM Security Model has no need of values in the tmStateReference 1186 cache to authenticate and secure the SNMP message, but an application 1187 might have chosen to use a secure transport such as that provided by 1188 the SSH Transport Model to send the message to its destination. 1190 7. Security Considerations 1192 This document defines an architectural approach that permits SNMP to 1193 utilize transport layer security services. Each proposed Transport 1194 Model should discuss the security considerations of the Transport 1195 Model. 1197 It is considered desirable by some industry segments that SNMP 1198 Transport Models should utilize transport layer security that 1199 addresses perfect forward secrecy at least for encryption keys. 1200 Perfect forward secrecy guarantees that compromise of long term 1201 secret keys does not result in disclosure of past session keys. Each 1202 proposed Transport Model should include a discussion in its security 1203 considerations of whether perfect forward security is appropriate for 1204 the Transport Model. 1206 Since the cache and LCD will contain security-related parameters, 1207 implementers should store this information (in memory or in 1208 persistent storage) in a manner to protect it from unauthorized 1209 disclosure and/or modification. 1211 Care must be taken to ensure that a SNMP engine is sending packets 1212 out over a transport using credentials that are legal for that engine 1213 to use on behalf of that user. Otherwise an engine that has multiple 1214 transports open might be "tricked" into sending a message through the 1215 wrong transport. 1217 8. IANA Considerations 1219 This document requires no action by IANA. 1221 9. Acknowledgments 1223 The Integrated Security for SNMP WG would like to thank the following 1224 people for their contributions to the process: 1226 The authors of submitted Security Model proposals: Chris Elliot, Wes 1227 Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David 1228 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1230 The members of the Protocol Evaluation Team: Uri Blumenthal, 1231 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1233 WG members who committed to and performed detailed reviews: Jeffrey 1234 Hutzelman 1236 10. References 1238 10.1. Normative References 1240 [RFC2119] Bradner, S., "Key words for 1241 use in RFCs to Indicate 1242 Requirement Levels", 1243 BCP 14, RFC 2119, 1244 March 1997. 1246 [RFC3411] Harrington, D., Presuhn, 1247 R., and B. Wijnen, "An 1248 Architecture for Describing 1249 Simple Network Management 1250 Protocol (SNMP) Management 1251 Frameworks", STD 62, 1252 RFC 3411, December 2002. 1254 [RFC3412] Case, J., Harrington, D., 1255 Presuhn, R., and B. Wijnen, 1256 "Message Processing and 1257 Dispatching for the Simple 1258 Network Management Protocol 1259 (SNMP)", STD 62, RFC 3412, 1260 December 2002. 1262 [RFC3414] Blumenthal, U. and B. 1263 Wijnen, "User-based 1264 Security Model (USM) for 1265 version 3 of the Simple 1266 Network Management Protocol 1267 (SNMPv3)", STD 62, 1268 RFC 3414, December 2002. 1270 [RFC3417] Presuhn, R., "Transport 1271 Mappings for the Simple 1272 Network Management Protocol 1273 (SNMP)", STD 62, RFC 3417, 1274 December 2002. 1276 10.2. Informative References 1278 [RFC2865] Rigney, C., Willens, S., 1279 Rubens, A., and W. Simpson, 1280 "Remote Authentication Dial 1281 In User Service (RADIUS)", 1282 RFC 2865, June 2000. 1284 [RFC3410] Case, J., Mundy, R., 1285 Partain, D., and B. 1286 Stewart, "Introduction and 1287 Applicability Statements 1288 for Internet-Standard 1289 Management Framework", 1290 RFC 3410, December 2002. 1292 [RFC3413] Levi, D., Meyer, P., and B. 1293 Stewart, "Simple Network 1294 Management Protocol (SNMP) 1295 Applications", STD 62, 1296 RFC 3413, December 2002. 1298 [RFC4366] Blake-Wilson, S., Nystrom, 1299 M., Hopwood, D., Mikkelsen, 1300 J., and T. Wright, 1301 "Transport Layer Security 1302 (TLS) Extensions", 1303 RFC 4366, April 2006. 1305 [RFC4422] Melnikov, A. and K. 1306 Zeilenga, "Simple 1307 Authentication and Security 1308 Layer (SASL)", RFC 4422, 1309 June 2006. 1311 [RFC4251] Ylonen, T. and C. Lonvick, 1312 "The Secure Shell (SSH) 1313 Protocol Architecture", 1314 RFC 4251, January 2006. 1316 [RFC4741] Enns, R., "NETCONF 1317 Configuration Protocol", 1318 RFC 4741, December 2006. 1320 [I-D.ietf-isms-transport-security-model] Harrington, D., "Transport 1321 Security Model for SNMP", d 1322 raft-ietf-isms-transport- 1323 security-model-02 (work in 1324 progress), January 2007. 1326 Appendix A. Parameter Table 1328 Following is a Comma-separated-values (CSV) formatted matrix useful 1329 for tracking data flows into and out of the dispatcher, Transport, 1330 Message Processing, and Security Subsystems. This will be of most 1331 use to designers of models, to understand what information is 1332 available at which points in the processing, following the RFC3411 1333 architecture (and this subsystem). Import this into your favorite 1334 spreadsheet or other CSV compatible application. You will need to 1335 remove lines feeds from the second, third, and fourth lines, which 1336 needed to be wrapped to fit into RFC line lengths. 1338 A.1. ParameterList.csv 1340 ,Dispatcher,,,,Messaging,,,Security,,,Transport, 1341 ,sendPDU,returnResponse,processPDU,processResponse, 1343 prepareOutgoingMessage,prepareResponseMessage,prepareDataElements, 1345 generateRequest,processIncoming,generateResponse, 1347 sendMessage,receiveMessage 1349 transportDomain,In,,,,In,,In,,,,,In 1351 transportAddress,In,,,,In,,In,,,,,In 1353 destTransportDomain,,,,,Out,Out,,,,,In, 1355 destTransportAddress,,,,,Out,Out,,,,,In, 1357 messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,, 1359 securityModel,In,In,In,In,In,In,Out,In,In,In,, 1361 securityName,In,In,In,In,In,In,Out,In,Out,In,, 1363 securityLevel,In,In,In,In,In,In,Out,In,In,In,, 1365 contextEngineID,In,In,In,In,In,In,Out,,,,, 1367 contextName,In,In,In,In,In,In,Out,,,,, 1369 expectResponse,In,,,,In,,,,,,, 1371 PDU,In,In,In,In,In,In,Out,,,,, 1373 pduVersion,In,In,In,In,In,In,Out,,,,, 1375 statusInfo,Out,In,,In,,In,Out,Out,Out,Out,, 1377 errorIndication,Out,Out,,,,,Out,,,,, 1379 sendPduHandle,Out,,,In,In,,Out,,,,, 1381 maxSizeResponsePDU,,In,In,,,In,Out,,Out,,, 1383 stateReference,,In,In,,,In,Out,,,,, 1385 wholeMessage,,,,,Out,Out,In,Out,In,Out,In,In 1387 messageLength,,,,,Out,Out,In,Out,In,Out,In,In 1388 maxMessageSize,,,,,,,,In,In,In,, 1390 globalData,,,,,,,,In,,In,, 1392 securityEngineID,,,,,,,,In,Out,In,, 1394 scopedPDU,,,,,,,,In,Out,In,, 1396 securityParameters,,,,,,,,Out,In,Out,, 1398 securityStateReference,,,,,,,,,Out,In,, 1400 pduType,,,,,,,Out,,,,, 1402 tmStateReference,,,,,Out,Out,In,,In,,In,In 1404 Appendix B. Why tmStateReference? 1406 This appendix considers why a cache-based approach was selected for 1407 passing parameters. 1409 There are four approaches that could be used for passing information 1410 between the Transport Model and a Security Model. 1412 1. one could define an ASI to supplement the existing ASIs, or 1413 2. one could add a header to encapsulate the SNMP message, 1414 3. one could utilize fields already defined in the existing SNMPv3 1415 message, or 1416 4. one could pass the information in an implementation-specific 1417 cache or via a MIB module. 1419 B.1. Define an Abstract Service Interface 1421 Abstract Service Interfaces (ASIs) are defined by a set of primitives 1422 that specify the services provided and the abstract data elements 1423 that are to be passed when the services are invoked. Defining 1424 additional ASIs to pass the security and transport information from 1425 the Transport Subsystem to Security Subsystem has the advantage of 1426 being consistent with existing RFC3411/3412 practice, and helps to 1427 ensure that any Transport Model proposals pass the necessary data, 1428 and do not cause side effects by creating model-specific dependencies 1429 between itself and other models or other subsystems other than those 1430 that are clearly defined by an ASI. 1432 B.2. Using an Encapsulating Header 1434 A header could encapsulate the SNMP message to pass necessary 1435 information from the Transport Model to the dispatcher and then to a 1436 Message Processing Model. The message header would be included in 1437 the wholeMessage ASI parameter, and would be removed by a 1438 corresponding Message Processing Model. This would imply the (one 1439 and only) messaging dispatcher would need to be modified to determine 1440 which SNMP message version was involved, and a new Message Processing 1441 Model would need to be developed that knew how to extract the header 1442 from the message and pass it to the Security Model. 1444 B.3. Modifying Existing Fields in an SNMP Message 1446 [RFC3412] defines the SNMPv3 message, which contains fields to pass 1447 security related parameters. The Transport Subsystem could use these 1448 fields in an SNMPv3 message, or comparable fields in other message 1449 formats to pass information between Transport Models in different 1450 SNMP engines, and to pass information between a Transport Model and a 1451 corresponding Message Processing Model. 1453 If the fields in an incoming SNMPv3 message are changed by the 1454 Transport Model before passing it to the Security Model, then the 1455 Transport Model will need to decode the ASN.1 message, modify the 1456 fields, and re-encode the message in ASN.1 before passing the message 1457 on to the message dispatcher or to the transport layer. This would 1458 require an intimate knowledge of the message format and message 1459 versions so the Transport Model knew which fields could be modified. 1460 This would seriously violate the modularity of the architecture. 1462 B.4. Using a Cache 1464 This document describes a cache, into which the Transport Model puts 1465 information about the security applied to an incoming message, and a 1466 Security Model can extract that information from the cache. Given 1467 that there might be multiple TM-security caches, a tmStateReference 1468 is passed as an extra parameter in the ASIs between the Transport 1469 Subsystem and the Security Subsystem, so the Security Model knows 1470 which cache of information to consult. 1472 This approach does create dependencies between a specific Transport 1473 Model and a corresponding specific Security Model. However, the 1474 approach of passing a model-independent reference to a model- 1475 dependent cache is consistent with the securityStateReference already 1476 being passed around in the RFC3411 ASIs. 1478 Appendix C. Open Issues 1480 NOTE to RFC editor: If this section is empty, then please remove this 1481 open issues section before publishing this document as an RFC. (If 1482 it is not empty, please send it back to the editor to resolve. 1484 o MUST responses go back on the same session? 1485 o How should we describe the case where a management system wants to 1486 keep session info available for inspection after a session has 1487 closed? see "Abstract Service Interfaces" 1488 o Do Informs work correctly? 1489 o How does a Transport Model know whether a message is a 1490 notification or a request/response? 1491 o cache contents - do we define this? 1493 Appendix D. Change Log 1495 NOTE to RFC editor: Please remove this change log before publishing 1496 this document as an RFC. 1498 Changes from revision -05- to -06- 1500 mostly editorial changes 1501 removed some paragraphs considered unnecessary 1502 added Updates to header 1503 modified some text to get the security details right 1504 modified text re: ASIs so they are not API-like 1505 cleaned up some diagrams 1506 cleaned up RFC2119 language 1507 added section numbers to citations to RFC3411 1508 removed gun for political correctness 1510 Changes from revision -04- to -05- 1512 removed all objects from the MIB module. 1513 changed document status to "Standard" rather than the xml2rfc 1514 default of informational. 1516 changed mention of MD5 to SHA 1517 moved addressing style to TDomain and TAddress 1518 modified the diagrams as requested 1519 removed the "layered stack" diagrams that compared USM and a 1520 Transport Model processing 1521 removed discussion of speculative features that might exist in 1522 future Transport Models 1523 removed openSession and closeSession ASIs, since those are model- 1524 dependent 1525 removed the MIB module 1526 removed the MIB boilerplate intro (this memo defines a SMIv2 MIB 1527 ...) 1528 removed IANA considerations related to the now-gone MIB module 1529 removed security considerations related to the MIB module 1530 removed references needed for the MIB module 1531 changed receiveMessage ASI to use origin transport domain/address 1532 updated Parameter CSV appendix 1533 Changes from revision -03- to -04- 1535 changed title from Transport Mapping Security Model Architectural 1536 Extension to Transport Subsystem 1537 modified the abstract and introduction 1538 changed TMSM to TMS 1539 changed MPSP to simply Security Model 1540 changed SMSP to simply Security Model 1541 changed TMSP to Transport Model 1542 removed MPSP and TMSP and SMSP from Acronyms section 1543 modified diagrams 1544 removed most references to dispatcher functionality 1545 worked to remove dependencies between transport and security 1546 models. 1547 defined snmpTransportModel enumeration similar to 1548 snmpSecurityModel, etc. 1549 eliminated all reference to SNMPv3 msgXXXX fields 1550 changed tmSessionReference back to tmStateReference 1552 Changes from revision -02- to -03- 1554 o removed session table from MIB module 1555 o removed sessionID from ASIs 1556 o reorganized to put ASI discussions in EOP section, as was done in 1557 SSHSM 1558 o changed user auth to client auth 1559 o changed tmStateReference to tmSessionReference 1560 o modified document to meet consensus positions published by JS 1561 o 1562 * authoritative is model-specific 1563 * msgSecurityParameters usage is model-specific 1564 * msgFlags vs. securityLevel is model/implementation-specific 1565 * notifications must be able to cause creation of a session 1566 * security considerations must be model-specific 1567 * TDomain and TAddress are model-specific 1568 * MPSP changed to SMSP (Security Model security processing) 1570 Changes from revision -01- to -02- 1572 o wrote text for session establishment requirements section. 1573 o wrote text for session maintenance requirements section. 1574 o removed section on relation to SNMPv2-MIB 1575 o updated MIB module to pass smilint 1576 o Added Structure of the MIB module, and other expected MIB-related 1577 sections. 1578 o updated author address 1579 o corrected spelling 1580 o removed msgFlags appendix 1581 o Removed section on implementation considerations. 1582 o started modifying the security boilerplate to address TMS and MIB 1583 security issues 1584 o reorganized slightly to better separate requirements from proposed 1585 solution. This probably needs additional work. 1586 o removed section with sample protocols and sample 1587 tmSessionReference. 1588 o Added section for acronyms 1589 o moved section comparing parameter passing techniques to appendix. 1590 o Removed section on notification requirements. 1592 Changes from revision -00- 1593 o changed SSH references from I-Ds to RFCs 1594 o removed parameters from tmSessionReference for DTLS that revealed 1595 lower layer info. 1596 o Added TMS-MIB module 1597 o Added Internet-Standard Management Framework boilerplate 1598 o Added Structure of the MIB Module 1599 o Added MIB security considerations boilerplate (to be completed) 1600 o Added IANA Considerations 1601 o Added ASI Parameter table 1602 o Added discussion of Sessions 1603 o Added Open issues and Change Log 1604 o Rearranged sections 1606 Authors' Addresses 1608 David Harrington 1609 Huawei Technologies (USA) 1610 1700 Alma Dr. Suite 100 1611 Plano, TX 75075 1612 USA 1614 Phone: +1 603 436 8634 1615 EMail: dharrington@huawei.com 1616 Juergen Schoenwaelder 1617 International University Bremen 1618 Campus Ring 1 1619 28725 Bremen 1620 Germany 1622 Phone: +49 421 200-3587 1623 EMail: j.schoenwaelder@iu-bremen.de 1625 Full Copyright Statement 1627 Copyright (C) The IETF Trust (2007). 1629 This document is subject to the rights, licenses and restrictions 1630 contained in BCP 78, and except as set forth therein, the authors 1631 retain all their rights. 1633 This document and the information contained herein are provided on an 1634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1636 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1637 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1638 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1641 Intellectual Property 1643 The IETF takes no position regarding the validity or scope of any 1644 Intellectual Property Rights or other rights that might be claimed to 1645 pertain to the implementation or use of the technology described in 1646 this document or the extent to which any license under such rights 1647 might or might not be available; nor does it represent that it has 1648 made any independent effort to identify any such rights. Information 1649 on the procedures with respect to rights in RFC documents can be 1650 found in BCP 78 and BCP 79. 1652 Copies of IPR disclosures made to the IETF Secretariat and any 1653 assurances of licenses to be made available, or the result of an 1654 attempt made to obtain a general license or permission for the use of 1655 such proprietary rights by implementers or users of this 1656 specification can be obtained from the IETF on-line IPR repository at 1657 http://www.ietf.org/ipr. 1659 The IETF invites any interested party to bring to its attention any 1660 copyrights, patents or patent applications, or other proprietary 1661 rights that may cover technology that may be required to implement 1662 this standard. Please address the information to the IETF at 1663 ietf-ipr@ietf.org. 1665 Acknowledgement 1667 Funding for the RFC Editor function is provided by the IETF 1668 Administrative Support Activity (IASA).