idnits 2.17.1 draft-ietf-isms-tmsm-07.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 1481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1505. 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 391 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 (March 4, 2007) is 6260 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) == Unused Reference: 'RFC3413' is defined on line 1124, but no explicit reference was found in the text -- 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 (~~), 3 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 March 4, 2007 7 Expires: September 5, 2007 9 Transport Subsystem for the Simple Network Management Protocol (SNMP) 10 draft-ietf-isms-tmsm-07 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 September 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. The Internet-Standard Management Framework . . . . . . . . 3 57 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 3 58 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Requirements of a Transport Model . . . . . . . . . . . . . . 7 61 3.1. Message Security Requirements . . . . . . . . . . . . . . 7 62 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7 63 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8 64 3.2.1. Architectural Modularity Requirements . . . . . . . . 8 65 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12 66 3.2.3. Security Parameter Passing Requirements . . . . . . . 13 67 3.2.4. Separation of Authentication and Authorization . . . . 14 68 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14 69 3.3.1. Session Establishment Requirements . . . . . . . . . . 15 70 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16 71 3.3.3. Message security versus session security . . . . . . . 16 72 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17 73 5. Cached Information and References . . . . . . . . . . . . . . 17 74 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18 75 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18 76 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19 77 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19 78 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20 79 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 21 80 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 87 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 26 88 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 26 89 Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 28 90 B.1. Define an Abstract Service Interface . . . . . . . . . . . 28 91 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 28 92 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 29 93 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 29 94 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 29 95 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 30 97 1. Introduction 99 This document defines a Transport Subsystem, extending the Simple 100 Network Management Protocol (SNMP) architecture defined in [RFC3411]. 101 This document identifies and describes some key aspects that need to 102 be considered for any Transport Model for SNMP. 104 1.1. The Internet-Standard Management Framework 106 For a detailed overview of the documents that describe the current 107 Internet-Standard Management Framework, please refer to section 7 of 108 RFC 3410 [RFC3410]. 110 1.2. Where this Extension Fits 112 It is expected that readers of this document will have read RFC3410 113 and RFC3411, and have a general understanding of the functionality 114 defined in RFCs 3412-3418. 116 The "Transport Subsystem" is an additional component for the SNMP 117 Engine depicted in RFC3411, section 3.1. 119 The following diagram depicts its place in the RFC3411 architecture.: 121 +-------------------------------------------------------------------+ 122 | SNMP entity | 123 | | 124 | +-------------------------------------------------------------+ | 125 | | SNMP engine (identified by snmpEngineID) | | 126 | | | | 127 | | +------------+ | | 128 | | | Transport | | | 129 | | | Subsystem | | | 130 | | +------------+ | | 131 | | | | 132 | | +------------+ +------------+ +-----------+ +-----------+ | | 133 | | | Dispatcher | | Message | | Security | | Access | | | 134 | | | | | Processing | | Subsystem | | Control | | | 135 | | | | | Subsystem | | | | Subsystem | | | 136 | | +------------+ +------------+ +-----------+ +-----------+ | | 137 | +-------------------------------------------------------------+ | 138 | | 139 | +-------------------------------------------------------------+ | 140 | | Application(s) | | 141 | | | | 142 | | +-------------+ +--------------+ +--------------+ | | 143 | | | Command | | Notification | | Proxy | | | 144 | | | Generator | | Receiver | | Forwarder | | | 145 | | +-------------+ +--------------+ +--------------+ | | 146 | | | | 147 | | +-------------+ +--------------+ +--------------+ | | 148 | | | Command | | Notification | | Other | | | 149 | | | Responder | | Originator | | | | | 150 | | +-------------+ +--------------+ +--------------+ | | 151 | +-------------------------------------------------------------+ | 152 | | 153 +-------------------------------------------------------------------+ 155 The transport mappings defined in RFC3417 do not provide lower-layer 156 security functionality, and thus do not provide transport-specific 157 security parameters. This document updates RFC3411 and RFC3417 by 158 defining an architectural extension and ASIs that transport mappings 159 (models) can use to pass transport-specific security parameters to 160 other subsystems, including transport-specific security parameters 161 translated into the transport-independent securityName and 162 securityLevel. 164 1.3. Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 The key words "must", "must not", "required", "shall", "shall not", 171 "should", "should not", "recommended", "may", and "optional" in this 172 document are not to be interpreted as described in RFC2119. They 173 will usually, but not always, be used in a context relating to 174 compatibility with the RFC3411 architecture or the subsystem defined 175 here, but which might have no impact on on-the-wire compatibility. 176 These terms are used as guidance for designers of proposed IETF 177 models to make the designs compatible with RFC3411 subsystems and 178 Abstract Service Interfaces (see section 3.2). Implementers are free 179 to implement differently. Some usages of these lowercase terms are 180 simply normal English usage. 182 2. Motivation 184 Just as there are multiple ways to secure one's home or business, in 185 a continuum of alternatives, there are multiple ways to secure a 186 network management protocol. Let's consider three general 187 approaches. 189 In the first approach, an individual could sit on his front porch 190 waiting for intruders. In the second approach, he could hire an 191 employee , schedule the employee, position the employee to guard what 192 he wants protected, hire a second guard to cover if the first gets 193 sick, and so on. In the third approach, he could hire a security 194 company, tell them what he wants protected, and they could hire 195 employees, train them, position the guards, schedule the guards, send 196 a replacement when a guard cannot make it, etc., thus providing the 197 desired security, with no significant effort on his part other than 198 identifying requirements and verifying the quality of the service 199 being provided. 201 The User-based Security Model (USM) as defined in [RFC3414] largely 202 uses the first approach - it provides its own security. It utilizes 203 existing mechanisms (e.g., SHA), but provides all the coordination. 204 USM provides for the authentication of a principal, message 205 encryption, data integrity checking, timeliness checking, etc. 207 USM was designed to be independent of other existing security 208 infrastructures. USM therefore requires a separate principal and key 209 management infrastructure. Operators have reported that deploying 210 another principal and key management infrastructure in order to use 211 SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use 212 external mechanisms to handle the distribution of keys for use by 213 USM. The more important issue is that operators wanted to leverage a 214 single user base that wasn't specific to SNMP. 216 A solution based on the second approach might use a USM-compliant 217 architecture, but combine the authentication mechanism with an 218 external mechanism, such as RADIUS [RFC2865], to provide the 219 authentication service. It might be possible to utilize an external 220 protocol to encrypt a message, to check timeliness, to check data 221 integrity, etc. It is difficult to cobble together a number of 222 subcontracted services and coordinate them however, because it is 223 difficult to build solid security bindings between the various 224 services, and potential for gaps in the security is significant. 226 A solution based on the third approach might utilize one or more 227 lower-layer security mechanisms to provide the message-oriented 228 security services required. These would include authentication of 229 the sender, encryption, timeliness checking, and data integrity 230 checking. There are a number of IETF standards available or in 231 development to address these problems through security layers at the 232 transport layer or application layer, among them TLS [RFC4366], SASL 233 [RFC4422], and SSH [RFC4251]. 235 From an operational perspective, it is highly desirable to use 236 security mechanisms that can unify the administrative security 237 management for SNMPv3, command line interfaces (CLIs) and other 238 management interfaces. The use of security services provided by 239 lower layers is the approach commonly used for the CLI, and is also 240 the approach being proposed for NETCONF [RFC4741]. 242 This document defines a Transport Subsystem extension to the RFC3411 243 architecture based on the third approach. This extension specifies 244 how other lower layer protocols with common security infrastructures 245 can be used underneath the SNMP protocol and the desired goal of 246 unified administrative security can be met. 248 This extension allows security to be provided by an external protocol 249 connected to the SNMP engine through an SNMP Transport Model 250 [RFC3417]. Such a Transport Model would then enable the use of 251 existing security mechanisms such as (TLS) [RFC4366] or SSH [RFC4251] 252 within the RFC3411 architecture. 254 There are a number of Internet security protocols and mechanisms that 255 are in wide spread use. Many of them try to provide a generic 256 infrastructure to be used by many different application layer 257 protocols. The motivation behind the Transport Subsystem is to 258 leverage these protocols where it seems useful. 260 There are a number of challenges to be addressed to map the security 261 provided by a secure transport into the SNMP architecture so that 262 SNMP continues to provide interoperability with existing 263 implementations. These challenges are described in detail in this 264 document. For some key issues, design choices are described that 265 might be made to provide a workable solution that meets operational 266 requirements and fits into the SNMP architecture defined in 267 [RFC3411]. 269 3. Requirements of a Transport Model 271 3.1. Message Security Requirements 273 Transport security protocols SHOULD provide protection against the 274 following message-oriented threats [RFC3411]: 276 1. modification of information 277 2. masquerade 278 3. message stream modification 279 4. disclosure 281 These threats are described in section 1.4 of [RFC3411]. It is not 282 required to protect against denial of service or traffic analysis, 283 but it should not make those threats significantly worse. 285 3.1.1. Security Protocol Requirements 287 There are a number of standard protocols that could be proposed as 288 possible solutions within the Transport Subsystem. Some factors 289 SHOULD be considered when selecting a protocol. 291 Using a protocol in a manner for which it was not designed has 292 numerous problems. The advertised security characteristics of a 293 protocol might depend on it being used as designed; when used in 294 other ways, it might not deliver the expected security 295 characteristics. It is recommended that any proposed model include a 296 description of the applicability of the Transport Model. 298 A Transport Model SHOULD require no modifications to the underlying 299 protocol. Modifying the protocol might change its security 300 characteristics in ways that would impact other existing usages. If 301 a change is necessary, the change SHOULD be an extension that has no 302 impact on the existing usages. Any Transport Model SHOULD include a 303 description of potential impact on other usages of the protocol. 305 Transport Models MUST be able to coexist with each other. 307 3.2. SNMP Requirements 309 3.2.1. Architectural Modularity Requirements 311 SNMP version 3 (SNMPv3) is based on a modular architecture (defined 312 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 313 standards over time, and to minimize side effects between subsystems 314 when changes are made. 316 The RFC3411 architecture includes a Security Subsystem for enabling 317 different methods of providing security services, a Message 318 Processing Subsystem permitting different message versions to be 319 handled by a single engine, Applications(s) to support different 320 types of application processors, and an Access Control Subsystem for 321 allowing multiple approaches to access control. The RFC3411 322 architecture does not include a subsystem for Transport Models, 323 despite the fact there are multiple transport mappings already 324 defined for SNMP. This document addresses the need for a Transport 325 Subsystem compatible with the RFC3411 architecture. As work is being 326 done to expand the transport to include secure transport such as SSH 327 and TLS, using a subsystem will enable consistent design and 328 modularity of such Transport Models. 330 The design of this Transport Subsystem accepts the goals of the 331 RFC3411 architecture defined in section 1.5 of [RFC3411]. This 332 Transport Subsystem uses a modular design that will permit Transport 333 Models to be advanced through the standards process independently of 334 other Transport Models, and independent of other modular SNMP 335 components as much as possible. 337 Parameters have been added to the ASIs to pass model-independent 338 transport address information. 340 IETF standards typically require one mandatory to implement solution, 341 with the capability of adding new mechanisms in the future. Part of 342 the motivation of developing Transport Models is to develop support 343 for secure transport protocols, such as a Transport Model that 344 utilizes the Secure Shell protocol. Any Transport Model SHOULD 345 define one minimum-compliance security mechanism, such as 346 certificates, to ensure a basic level of interoperability, but should 347 also be able to support additional existing and new mechanisms. 349 The Transport Subsystem permits multiple transport protocols to be 350 "plugged into" the RFC3411 architecture, supported by corresponding 351 Transport Models, including models that are security-aware. 353 The RFC3411 architecture and the Security Subsystem assume that a 354 Security Model is called by a Message Processing Model and will 355 perform multiple security functions within the Security Subsystem. A 356 Transport Model that supports a secure transport protocol might 357 perform similar security functions within the Transport Subsystem. A 358 Transport Model might perform the translation of transport security 359 parameters to/from security-model-independent parameters. 361 To accommodate this, an implementation-specific cache of transport- 362 specific information will be described (not shown), and the data 363 flows between the Transport Subsystem and the Transport Dispatch, 364 between the Message Dispatch and the Message Processing Subsystem, 365 and between the Message Processing Subsystem and the Security 366 Subsystem will be extended to pass security-model-independent values. 367 New Security Models may also be defined that understand how to work 368 with the modified ASIs and the cache. One such Security Model, the 369 Transport Security Model, is defined in 370 [I-D.ietf-isms-transport-security-model] 372 The following diagram depicts the SNMPv3 architecture including the 373 new Transport Subsystem defined in this document, and a new Transport 374 Security Model defined in [I-D.ietf-isms-transport-security-model]. 376 +------------------------------+ 377 | Network | 378 +------------------------------+ 379 ^ ^ ^ 380 | | | 381 v v v 382 +-------------------------------------------------------------------+ 383 | +--------------------------------------------------+ | 384 | | Transport Subsystem | | 385 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 386 | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | 387 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | 388 | +--------------------------------------------------+ | 389 | ^ | 390 | | | 391 | Dispatcher v | 392 | +-------------------+ +---------------------+ +----------------+ | 393 | | Transport | | Message Processing | | Security | | 394 | | Dispatch | | Subsystem | | Subsystem | | 395 | | | | +------------+ | | +------------+ | | 396 | | | | +->| v1MP |<--->| | USM | | | 397 | | | | | +------------+ | | +------------+ | | 398 | | | | | +------------+ | | +------------+ | | 399 | | | | +->| v2cMP |<--->| | Transport | | | 400 | | Message | | | +------------+ | | | Security | | | 401 | | Dispatch <--------->| +------------+ | | | Model | | | 402 | | | | +->| v3MP |<--->| +------------+ | | 403 | | | | | +------------+ | | +------------+ | | 404 | | PDU Dispatch | | | +------------+ | | | Other | | | 405 | +-------------------+ | +->| otherMP |<--->| | Model(s) | | | 406 | ^ | +------------+ | | +------------+ | | 407 | | +---------------------+ +----------------+ | 408 | v | 409 | +-------+-------------------------+---------------+ | 410 | ^ ^ ^ | 411 | | | | | 412 | v v v | 413 | +-------------+ +---------+ +--------------+ +-------------+ | 414 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 415 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 416 | | application | | | | applications | | application | | 417 | +-------------+ +---------+ +--------------+ +-------------+ | 418 | ^ ^ | 419 | | | | 420 | v v | 421 | +----------------------------------------------+ | 422 | | MIB instrumentation | SNMP entity | 423 +-------------------------------------------------------------------+ 425 3.2.1.1. Processing Differences between USM and Secure Transport 427 USM and secure transports differ is the processing order and 428 responsibilities within the RFC3411 architecture. While the steps 429 are the same, they occur in a different order, and may be done by 430 different subsystems. The following lists illustrate the difference 431 in the flow and the responsibility for different processing steps for 432 incoming messages when using USM and when using a secure transport. 433 (Note that these lists are simplified for illustrative purposes, and 434 do not represent all details of processing. Transport Models must 435 provide the detailed elements of procedure.) 437 With USM and other Security Models, security processing starts when 438 the Message Processing Model decodes portions of the ASN.1 message to 439 extract an opaque block of security parameters and header parameters 440 that identify which Security Model should process the message to 441 perform authentication, decryption, timeliness checking, integrity 442 checking, and translation of parameters to model-independent 443 parameters. A secure transport performs those security functions on 444 the message, before the ASN.1 is decoded. 446 Step 6 cannot occur until after decryption occurs. Step 6 and beyond 447 are the same for USM and a secure transport. 449 3.2.1.1.1. USM and the RFC3411 Architecture 451 1) decode the ASN.1 header (Message Processing Model) 452 2) determine the SNMP Security Model and parameters (Message 453 Processing Model) 454 3) verify securityLevel. [Security Model] 455 4) translate parameters to model-independent parameters (Security 456 Model) 457 5) authenticate and decrypt message. [Security Model] 458 6) determine the pduType in the decrypted portions (Message 459 Processing Model), and 460 7) pass on the decrypted portions with model-independent parameters. 462 3.2.1.2. Transport Subsystem and the RFC3411 Architecture 464 1) authenticate and decrypt message. [Transport Model] 465 2) translate parameters to model-independent parameters (Transport 466 Model) 467 3) decode the ASN.1 header (Message Processing Model) 468 4) determine the SNMP Security Model and parameters (Message 469 Processing Model) 471 5) verify securityLevel [Security Model] 472 6) determine the pduType in the decrypted portions (Message 473 Processing Model), and 474 7) pass on the decrypted portions with model-independent security 475 parameters 477 If a message is secured using a secure transport layer, then the 478 Transport Model should provide the translation from the authenticated 479 identity (e.g., an SSH user name) to the securityName in step 3. 481 3.2.1.3. Passing Information between Engines 483 A secure Transport Model will establish an authenticated and/or 484 encrypted tunnel between the Transport Models of two SNMP engines. 485 After a transport layer tunnel is established, then SNMP messages can 486 be sent through the tunnel from one SNMP engine to the other SNMP 487 engine. Transport Models MAY support sending multiple SNMP messages 488 through the same tunnel. 490 3.2.2. Access Control Requirements 492 RFC3411 made some design decisions related to the support of an 493 Access Control Subsystem. These include a securityName and 494 securityLevel mapping, the separation of Authentication and 495 Authorization, and the passing of model-independent security 496 parameters. 498 3.2.2.1. securityName and securityLevel Mapping 500 For SNMP access control to function properly, Security Models MUST 501 establish a securityLevel and a securityName, which is the security- 502 model-independent identifier for a principal. The Message Processing 503 Subsystem relies on a Security Model, such as USM, to play a role in 504 security that goes beyond protecting the message - it provides a 505 mapping between the security-model-specific principal to a security- 506 model independent securityName which can be used for subsequent 507 processing, such as for access control. 509 The securityName MUST be mapped from the mechanism-specific 510 authenticated identity, and this mapping must be done for incoming 511 messages before the Security Model passes securityName to the Message 512 Processing Model via the processIncoming ASI. This translation from 513 a mechanism-specific authenticated identity to a securityName might 514 be done by the Transport Model, and the securityName is then provided 515 to the Security Model via the tmStateReference to be passed to the 516 Message Processing Model. 518 3.2.3. Security Parameter Passing Requirements 520 RFC3411 section 4 describes abstract data flows between the 521 subsystems, models and applications within the architecture. 522 Abstract Service Interfaces describe the flow of data, passing model- 523 independent information between subsystems within an engine. The 524 RFC3411 architecture has no ASI parameters for passing security 525 information between the Transport Subsystem and the dispatcher, or 526 between the dispatcher and the Message Processing Model. This 527 document defines or modifies ASIs for this purpose. 529 The security parameters include a model-independent identifier of the 530 security "principal" (the securityName), the Security Model used to 531 perform the authentication, and which authentication and privacy 532 services were (should be) applied to the message (securityLevel). 534 A Message Processing Model might unpack SNMP-specific security 535 parameters from an incoming message before calling a specific 536 Security Model to authenticate and decrypt an incoming message, 537 perform integrity checking, and translate security-model-specific 538 parameters into model-independent parameters. When using a secure 539 Transport Model, security parameters might be provided through means 540 other than carrying them in the SNMP message; the parameters for 541 incoming messages might be extracted from the transport layer by the 542 Transport Model before the message is passed to the Message 543 Processing Subsystem. 545 This document describes a cache mechanism (see Section 5), into which 546 the Transport Model puts information about the transport and security 547 parameters applied to a transport connection or an incoming message, 548 and a Security Model may extract that information from the cache. A 549 tmStateReference is passed as an extra parameter in the ASIs of the 550 Transport Subsystem and the Message Processing and Security 551 Subsystems, to identify the relevant cache. This approach of passing 552 a model-independent reference is consistent with the 553 securityStateReference cache already being passed around in the 554 RFC3411 ASIs. 556 For outgoing messages, even when a secure Transport Model will 557 provide the security services, a Message Processing Model might have 558 a Security Model actually create the message from its component 559 parts. Whether there are any security services provided by the 560 Security Model for an outgoing message is security-model-dependent. 561 For incoming messages, even when a secure Transport Model provides 562 security services, a Security Model might provide some security 563 functionality that can only be provided after the message version or 564 other parameters are extracted from the message. 566 3.2.4. Separation of Authentication and Authorization 568 The RFC3411 architecture defines a separation of authentication and 569 authorization (access control), and a Transport Model that provides 570 security services should take care to not violate this separation. A 571 Transport Model does not know which securityModel will be used for an 572 incoming message, so must not specify how the securityModel and 573 securityName could be dynamically mapped to an access control 574 mechanism, such as a VACM-style groupName. 576 The RECOMMENDED approach is to pass the model-independent security 577 parameters via the isAccessAllowed ASI, and perform the mapping from 578 the model-independent security parameters to an access-control-model- 579 dependent policy within the Access Control Model. The 580 isAccessAllowed ASI is used for passing the securityModel, 581 securityName, and securityLevel parameters that are independent of 582 any specific security model and any specific access control model to 583 the Access Control Subsystem. 585 The mapping of (securityModel, securityName, securityLevel) to an 586 access-control-model-specific policy should be handled within a 587 specific access control model. This mapping should not be done in 588 the Transport or Security Subsystems, to be consistent with the 589 modularity of the RFC3411 architecture. This separation was a 590 deliberate decision of the SNMPv3 WG, to allow support for 591 authentication protocols which did not provide authorization (access 592 control) capabilities, and to support authorization schemes, such as 593 VACM, that do not perform their own authentication. 595 The View-based Access Control Model uses the securityModel and the 596 securityName as inputs to check for access rights. It determines the 597 groupName as a function of securityModel and securityName. Providing 598 a binding outside the Access Control Subsystem might create 599 dependencies that could make it harder to develop alternate models of 600 access control, such as one built on UNIX groups or Windows domains. 602 3.3. Session Requirements 604 Some secure transports might have a notion of sessions, while other 605 secure transports might provide channels or other session-like 606 mechanism. Throughout this document, the term session is used in a 607 broad sense to cover sessions, channels, and session-like mechanisms. 608 Session refers to an association between two SNMP engines that 609 permits the transmission of one or more SNMP messages within the 610 lifetime of the session. How the session is actually established, 611 opened, closed, or maintained is specific to a particular Transport 612 Model. 614 Sessions are not part of the SNMP architecture defined in [RFC3411], 615 but are considered desirable because the cost of authentication can 616 be amortized over potentially many transactions. 618 The architecture defined in [RFC3411] does not include a session 619 selector in the Abstract Service Interfaces, and neither is that done 620 for the Transport Subsystem, so an SNMP application has no mechanism 621 to select a session using the ASIs except by passing a unique 622 combination of transportDomain, transportAddress, securityName, and 623 securityLevel. Implementers, of course, might provide non-standard 624 mechanisms to select sessions. The transportDomain and 625 transportAddress identify the transport connection to a remote 626 network node; the securityName identifies which security principal to 627 communicate with at that address (e.g., different NMS applications), 628 and the securityLevel might permit selection of different sets of 629 security properties for different purposes (e.g., encrypted SETs vs. 630 non-encrypted GETs). 632 To reduce redundancy, this document describes aspects that are 633 expected to be common to all Transport Model sessions. 635 3.3.1. Session Establishment Requirements 637 SNMP applications provide the transportDomain, transportAddress, 638 securityName, and securityLevel to be used to identify a session in a 639 transport-independent manner. 641 For an outgoing message, securityLevel is the requested security for 642 the message, passed in the ASIs. If the Transport Model cannot 643 provide at least the requested level of security, the Transport Model 644 SHOULD discard the message and notify the dispatcher that sending the 645 message failed. 647 A Transport Model determines whether an approrpiate session exists 648 (transportDomain, transportAddress, securityName, and securityLevel) 649 for an outgoing message. If an appropriate session does not yet 650 exist, the Transport Model attempts to establish a session for 651 delivery . If a session cannot be established then the message is 652 discarded and the dispatcher should be notified that sending the 653 message failed. 655 Depending on the secure transport protocol, session establishment 656 might require provisioning authentication credentials on the agent, 657 either statically or dynamically, so the client/agent can 658 successfully authenticate to a receiver. 660 The Transport Subsystem has no knowledge of pdutype, so cannot 661 distinguish between a session created to carry different pduTypes. 663 To differentiate a session established for different purposes, such 664 as a notification session versus a request-response session, an 665 application can use different securityNames or transport addresses 666 (e.g., port 161 vs. port 162). 668 3.3.2. Session Maintenance Requirements 670 A Transport Model can tear down sessions as needed. It might be 671 necessary for some implementations to tear down sessions as the 672 result of resource constraints, for example. 674 The decision to tear down a session is implementation-dependent. 675 While it is possible for an implementation to automatically tear down 676 each session once an operation has completed, this is not recommended 677 for anticipated performance reasons. How an implementation 678 determines that an operation has completed, including all potential 679 error paths, is implementation-dependent. 681 The elements of procedure describe when cached information can be 682 discarded, in some circumstances, and the timing of cache cleanup 683 might have security implications, but cache memory management is an 684 implementation issue. 686 If a Transport Model defines MIB module objects to maintain session 687 state information, then the Transport Model MUST define what SHOULD 688 happen to the objects when a related session is torn down, since this 689 will impact interoperability of the MIB module. 691 3.3.3. Message security versus session security 693 A Transport Model session is associated with state information that 694 is maintained for its lifetime. This state information allows for 695 the application of various security services to multiple messages. 696 Cryptographic keys established at the beginning of the session SHOULD 697 be used to provide authentication, integrity checking, and encryption 698 services for data that is communicated during the session. The 699 cryptographic protocols used to establish keys for a Transport Model 700 session SHOULD ensure that fresh new session keys are generated for 701 each session. In addition sequence information might be maintained 702 in the session which can be used to prevent the replay and reordering 703 of messages within a session. If each session uses new keys, then a 704 cross-session replay attack will be unsuccessful; that is, an 705 attacker cannot successfully replay on one session a message he 706 observed from another session. A good security protocol will also 707 protect against replay attacks _within_ a session; that is, an 708 attacker cannot successfully replay a message observed earlier in the 709 same session. 711 A Transport Model session will have a single transportDomain, 712 transportAddress, securityName and securityLevel associated with it. 713 If an exchange between communicating engines requires a different 714 securityLevel or is on behalf of a different securityName, then 715 another session would be needed. An immediate consequence of this is 716 that implementations SHOULD be able to maintain some reasonable 717 number of concurrent sessions. 719 For Transport Models, securityName should be specified during session 720 setup, and associated with the session identifier. 722 SNMPv3 was designed to support multiple levels of security, 723 selectable on a per-message basis by an SNMP application, because, 724 for example, there is not much value in using encryption for a 725 Commander Generator to poll for potentially non-sensitive performance 726 data on thousands of interfaces every ten minutes; the encryption 727 might add significant overhead to processing of the messages. 729 Some Transport Models might support only specific authentication and 730 encryption services, such as requiring all messages to be carried 731 using both authentication and encryption, regardless of the security 732 level requested by an SNMP application. A Transport Model may 733 upgrade the requested security level, i.e. noAuthNoPriv and 734 authNoPriv MAY be sent over an authenticated and encrypted session. 736 4. Scenario Diagrams and the Transport Subsystem 738 RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to 739 illustrate how an outgoing message is created, and how an incoming 740 message is processed. RFC3411 does not define ASIs for "Send SNMP 741 Request Message to Network" or "Receive SNMP Response Message from 742 Network", and does not define ASIs for "Receive SNMP Message from 743 Network" or "Send SNMP message to Network". 745 This document defines a sendMessage ASI to send SNMP messages to the 746 network, regardless of pduType, and a receiveMessage ASI to receive 747 SNMP messages from the network, regardless of pdutype. 749 5. Cached Information and References 751 The RFC3411 architecture uses caches to store dynamic model-specific 752 information, and uses references in the ASIs to indicate in a model- 753 independent manner which cached information flows between subsystems. 755 There are two levels of state that might need to be maintained: the 756 security state in a request-response pair, and potentially long-term 757 state relating to transport and security. 759 This state is maintained in caches. To simplify the elements of 760 procedure, the release of state information is not always explicitly 761 specified. As a general rule, if state information is available when 762 a message being processed gets discarded, the state related to that 763 message should also be discarded, and if state information is 764 available when a relationship between engines is severed, such as the 765 closing of a transport session, the state information for that 766 relationship might also be discarded. 768 This document differentiates the tmStateReference from the 769 securityStateReference. This document does not specify an 770 implementation strategy, only an abstract description of the data 771 that flows between subsystems. An implementation might use one cache 772 and one reference to serve both functions, but an implementer must be 773 aware of the cache-release issues to prevent the cache from being 774 released before a security or Transport Model has had an opportunity 775 to extract the information it needs. 777 5.1. securityStateReference 779 The securityStateReference parameter is defined in RFC3411. 780 securityStateReference is not accessible to models of the Transport 781 Subsystem. 783 5.2. tmStateReference 785 For each transport session, information about the message security is 786 stored in a cache to pass model- and mechanism-specific parameters. 787 The state referenced by tmStateReference may be saved across multiple 788 messages, in a Local Configuration Datastore (LCD), as compared to 789 securityStateReference which is usually only saved for the life of a 790 request-response pair of messages. 792 For security reasons, if a secure transport session is closed between 793 the time a request message is received and the corresponding response 794 message is sent, then the response message MUST be discarded, even if 795 a new session has been established. The tmStateReference captured 796 during processing of an incoming message SHOULD include a transport- 797 specific session identifier. Each Security Model SHOULD pass a 798 tmSameSession parameter in the tmStateReference cache for outgoing 799 messages to indicate whether the same session must be used for the 800 outgoing message as was used for the corresponding incoming message. 801 If the session identified in the tmStateReference does not match the 802 current established session, the message MUST be discarded, and the 803 dispatcher should be notified the sending of the message failed. 805 Since the contents of a cache are meaningful only within an 806 implementation, and not on-the-wire, the format of the cache and the 807 LCD are implementation-specific. 809 6. Abstract Service Interfaces 811 Abstract service interfaces have been defined by RFC 3411 to describe 812 the conceptual data flows between the various subsystems within an 813 SNMP entity, and to help keep the subsystems independent of each 814 other except for the common parameters. 816 This document follows the example of RFC3411 regarding the release of 817 state information, and regarding error indications. 819 1) The release of state information is not always explicitly 820 specified in a transport model. As a general rule, if state 821 information is available when a message gets discarded, the message- 822 state information should also be released, and if state information 823 is available when a session is closed, the session state information 824 should also be released. Note that keeping sensitive security 825 information longer than necessary might introduce potential 826 vulnerabilities to an implementation. 828 2) An error indication in statusInformation may include an OID and 829 value for an incremented counter and a value for securityLevel, and 830 values for contextEngineID and contextName for the counter, and the 831 securityStateReference if the information is available at the point 832 where the error is detected. 834 6.1. sendMessage ASI 836 The sendMessage ASI is used to pass a message from the Dispatcher to 837 the appropriate Transport Model for sending. 839 If present and valid, the tmStateReference refers to a cache 840 containing transport-model-specific parameters for the transport and 841 transport security. How the information in the cache is used is 842 transport-model-dependent and implementation-dependent. How a 843 tmStateReference is determined to be present and valid is 844 implementation-dependent. 846 This may sound underspecified, but keep in mind that a transport 847 model might be something like SNMP over UDP over IPv6, where no 848 security is provided, so it might have no mechanisms for utilizing a 849 securityName and securityLevel. 851 statusInformation = 852 sendMessage( 853 IN destTransportDomain -- transport domain to be used 854 IN destTransportAddress -- transport address to be used 855 IN outgoingMessage -- the message to send 856 IN outgoingMessageLength -- its length 857 IN tmStateReference -- reference to transport state 858 ) 860 6.2. Other Outgoing ASIs 862 A tmStateReference parameter has been added to the 863 prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg 864 ASIs as an OUT parameter. 866 statusInformation = -- success or errorIndication 867 prepareOutgoingMessage( 868 IN transportDomain -- transport domain to be used 869 IN transportAddress -- transport address to be used 870 IN messageProcessingModel -- typically, SNMP version 871 IN securityModel -- Security Model to use 872 IN securityName -- on behalf of this principal 873 IN securityLevel -- Level of Security requested 874 IN contextEngineID -- data from/at this entity 875 IN contextName -- data from/in this context 876 IN pduVersion -- the version of the PDU 877 IN PDU -- SNMP Protocol Data Unit 878 IN expectResponse -- TRUE or FALSE 879 IN sendPduHandle -- the handle for matching 880 incoming responses 881 OUT destTransportDomain -- destination transport domain 882 OUT destTransportAddress -- destination transport address 883 OUT outgoingMessage -- the message to send 884 OUT outgoingMessageLength -- its length 885 OUT tmStateReference -- (NEW) reference to transport state 886 ) 888 The tmStateReference parameter of generateRequestMsg or 889 generateResponseMsg is passed in the return parameters of the 890 Security Subsystem to the Message Processing Subsystem. If a cache 891 exists for a session identifiable from transportDomain, 892 transportAddress, securityModel, securityName, and securityLevel, 893 then an appropriate Security Model might create a tmStateReference to 894 the cache and pass that as an OUT parameter. 896 If one does not exist, the Security Model might create a cache 897 referenced by tmStateReference. This information might include 898 transportDomain, transportAddress, the securityLevel, and the 899 securityName, plus any model or mechanism-specific details. The 900 contents of the cache may be incomplete until the Transport Model has 901 established a session. What information is passed, and how this 902 information is determined, is implementation and security-model- 903 specific. 905 The prepareOutgoingMessage ASI passes tmStateReference from the 906 Message Processing Subsystem to the dispatcher. How or if the 907 Message Processing Subsystem modifies or utilizes the contents of the 908 cache is message-processing-model-specific. 910 This may sound underspecified, but keep in mind that a message 911 processing model might have access to all the information from the 912 cache and from the message, and have no need to call a Security Model 913 to do any processing; an application might choose a Security Model 914 such as USM to authenticate and secure the SNMP message, but also 915 utilize a secure transport such as that provided by the SSH Transport 916 Model to send the message to its destination. 918 6.3. The receiveMessage ASI 920 If one does not exist, the Transport Model might create a cache 921 referenced by tmStateReference. If present, this information might 922 include transportDomain, transportAddress, securityLevel, and 923 securityName, plus model or mechanism-specific details. How this 924 information is determined is implementation and transport-model- 925 specific. 927 This may sound underspecified, but keep in mind that a transport 928 model might be something like SNMP over UDP over IPv6, where no 929 security is provided, so it might have no mechanisms for determining 930 a securityName and securityLevel. 932 The Transport Model does not know the securityModel for an incoming 933 message; this will be determined by the Message Processing Model in a 934 message-processing-model-dependent manner. 936 The receiveMessage ASI is used to pass a message from the Transport 937 Subsystem to the Dispatcher. 939 statusInformation = 940 receiveMessage( 941 IN transportDomain -- origin transport domain 942 IN transportAddress -- origin transport address 943 IN incomingMessage -- the message received 944 IN incomingMessageLength -- its length 945 IN tmStateReference -- reference to transport state 946 ) 948 6.4. Other Incoming ASIs 950 To support the Transport Subsystem, the tmStateReference is added to 951 the prepareDataElements ASI (from the Dispatcher to the Message 952 Processing Subsystem), and to the processIncomingMsg ASI (from the 953 Message Processing Subsystem to the Security Model Subsystem). How 954 or if a Message Processing Model or Security Model uses 955 tmStateReference is message-processing-model-dependent and security- 956 model-dependent. 958 result = -- SUCCESS or errorIndication 959 prepareDataElements( 960 IN transportDomain -- origin transport domain 961 IN transportAddress -- origin transport address 962 IN wholeMsg -- as received from the network 963 IN wholeMsgLength -- as received from the network 964 IN tmStateReference -- (NEW) from the Transport Model 965 OUT messageProcessingModel -- typically, SNMP version 966 OUT securityModel -- Security Model to use 967 OUT securityName -- on behalf of this principal 968 OUT securityLevel -- Level of Security requested 969 OUT contextEngineID -- data from/at this entity 970 OUT contextName -- data from/in this context 971 OUT pduVersion -- the version of the PDU 972 OUT PDU -- SNMP Protocol Data Unit 973 OUT pduType -- SNMP PDU type 974 OUT sendPduHandle -- handle for matched request 975 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 976 OUT statusInformation -- success or errorIndication 977 -- error counter OID/value if error 978 OUT stateReference -- reference to state information 979 -- to be used for possible Response 980 ) 981 statusInformation = -- errorIndication or success 982 -- error counter OID/value if error 983 processIncomingMsg( 984 IN messageProcessingModel -- typically, SNMP version 985 IN maxMessageSize -- of the sending SNMP entity 986 IN securityParameters -- for the received message 987 IN securityModel -- for the received message 988 IN securityLevel -- Level of Security 989 IN wholeMsg -- as received on the wire 990 IN wholeMsgLength -- length as received on the wire 991 IN tmStateReference -- (NEW) from the Transport Model 992 OUT securityEngineID -- authoritative SNMP entity 993 OUT securityName -- identification of the principal 994 OUT scopedPDU, -- message (plaintext) payload 995 OUT maxSizeResponseScopedPDU -- maximum size sender can handle 996 OUT securityStateReference -- reference to security state 997 ) -- information, needed for response 999 The tmStateReference parameter of prepareDataElements is passed from 1000 the dispatcher to the Message Processing Subsystem. How or if the 1001 Message Processing Subsystem modifies or utilizes the contents of the 1002 cache is message-processing-model-specific. 1004 The processIncomingMessage ASI passes tmStateReference from the 1005 Message Processing Subsystem to the Security Subsystem. 1007 If tmStateReference is present and valid, an appropriate Security 1008 Model might utilize the information in the cache. How or if the 1009 Security Subsystem utilizes the information in the cache is security- 1010 model-specific. 1012 This may sound underspecified, but keep in mind that a message 1013 processing model might have access to all the information from the 1014 cache and from the message, and have no need to call a Security Model 1015 to do any processing. The Message Processing Model might determine 1016 that the USM Security Model is specified in an SNMPv3 message header; 1017 the USM Security Model has no need of values in the tmStateReference 1018 cache to authenticate and secure the SNMP message, but an application 1019 might have chosen to use a secure transport such as that provided by 1020 the SSH Transport Model to send the message to its destination. 1022 7. Security Considerations 1024 This document defines an architectural approach that permits SNMP to 1025 utilize transport layer security services. Each proposed Transport 1026 Model should discuss the security considerations of the Transport 1027 Model. 1029 It is considered desirable by some industry segments that SNMP 1030 Transport Models should utilize transport layer security that 1031 addresses perfect forward secrecy at least for encryption keys. 1032 Perfect forward secrecy guarantees that compromise of long term 1033 secret keys does not result in disclosure of past session keys. Each 1034 proposed Transport Model should include a discussion in its security 1035 considerations of whether perfect forward security is appropriate for 1036 the Transport Model. 1038 Since the cache and LCD will contain security-related parameters, 1039 implementers should store this information (in memory or in 1040 persistent storage) in a manner to protect it from unauthorized 1041 disclosure and/or modification. 1043 Care must be taken to ensure that a SNMP engine is sending packets 1044 out over a transport using credentials that are legal for that engine 1045 to use on behalf of that user. Otherwise an engine that has multiple 1046 transports open might be "tricked" into sending a message through the 1047 wrong transport. 1049 8. IANA Considerations 1051 This document requires no action by IANA. 1053 9. Acknowledgments 1055 The Integrated Security for SNMP WG would like to thank the following 1056 people for their contributions to the process: 1058 The authors of submitted Security Model proposals: Chris Elliot, Wes 1059 Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David 1060 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1062 The members of the Protocol Evaluation Team: Uri Blumenthal, 1063 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1065 WG members who committed to and performed detailed reviews: Jeffrey 1066 Hutzelman 1068 10. References 1070 10.1. Normative References 1072 [RFC2119] Bradner, S., "Key words for 1073 use in RFCs to Indicate 1074 Requirement Levels", 1075 BCP 14, RFC 2119, 1076 March 1997. 1078 [RFC3411] Harrington, D., Presuhn, 1079 R., and B. Wijnen, "An 1080 Architecture for Describing 1081 Simple Network Management 1082 Protocol (SNMP) Management 1083 Frameworks", STD 62, 1084 RFC 3411, December 2002. 1086 [RFC3412] Case, J., Harrington, D., 1087 Presuhn, R., and B. Wijnen, 1088 "Message Processing and 1089 Dispatching for the Simple 1090 Network Management Protocol 1091 (SNMP)", STD 62, RFC 3412, 1092 December 2002. 1094 [RFC3414] Blumenthal, U. and B. 1095 Wijnen, "User-based 1096 Security Model (USM) for 1097 version 3 of the Simple 1098 Network Management Protocol 1099 (SNMPv3)", STD 62, 1100 RFC 3414, December 2002. 1102 [RFC3417] Presuhn, R., "Transport 1103 Mappings for the Simple 1104 Network Management Protocol 1105 (SNMP)", STD 62, RFC 3417, 1106 December 2002. 1108 10.2. Informative References 1110 [RFC2865] Rigney, C., Willens, S., 1111 Rubens, A., and W. Simpson, 1112 "Remote Authentication Dial 1113 In User Service (RADIUS)", 1114 RFC 2865, June 2000. 1116 [RFC3410] Case, J., Mundy, R., 1117 Partain, D., and B. 1118 Stewart, "Introduction and 1119 Applicability Statements 1120 for Internet-Standard 1121 Management Framework", 1122 RFC 3410, December 2002. 1124 [RFC3413] Levi, D., Meyer, P., and B. 1125 Stewart, "Simple Network 1126 Management Protocol (SNMP) 1127 Applications", STD 62, 1128 RFC 3413, December 2002. 1130 [RFC4366] Blake-Wilson, S., Nystrom, 1131 M., Hopwood, D., Mikkelsen, 1132 J., and T. Wright, 1133 "Transport Layer Security 1134 (TLS) Extensions", 1135 RFC 4366, April 2006. 1137 [RFC4422] Melnikov, A. and K. 1138 Zeilenga, "Simple 1139 Authentication and Security 1140 Layer (SASL)", RFC 4422, 1141 June 2006. 1143 [RFC4251] Ylonen, T. and C. Lonvick, 1144 "The Secure Shell (SSH) 1145 Protocol Architecture", 1146 RFC 4251, January 2006. 1148 [RFC4741] Enns, R., "NETCONF 1149 Configuration Protocol", 1150 RFC 4741, December 2006. 1152 [I-D.ietf-isms-transport-security-model] Harrington, D., "Transport 1153 Security Model for SNMP", d 1154 raft-ietf-isms-transport- 1155 security-model-03 (work in 1156 progress), February 2007. 1158 Appendix A. Parameter Table 1160 Following is a Comma-separated-values (CSV) formatted matrix useful 1161 for tracking data flows into and out of the dispatcher, Transport, 1162 Message Processing, and Security Subsystems. This will be of most 1163 use to designers of models, to understand what information is 1164 available at which points in the processing, following the RFC3411 1165 architecture (and this subsystem). Import this into your favorite 1166 spreadsheet or other CSV compatible application. You will need to 1167 remove lines feeds from the second, third, and fourth lines, which 1168 needed to be wrapped to fit into RFC line lengths. 1170 A.1. ParameterList.csv 1172 ,Dispatcher,,,,Messaging,,,Security,,,Transport, 1173 ,sendPDU,returnResponse,processPDU,processResponse, 1175 prepareOutgoingMessage,prepareResponseMessage,prepareDataElements, 1177 generateRequest,processIncoming,generateResponse, 1179 sendMessage,receiveMessage 1181 transportDomain,In,,,,In,,In,,,,,In 1183 transportAddress,In,,,,In,,In,,,,,In 1185 destTransportDomain,,,,,Out,Out,,,,,In, 1187 destTransportAddress,,,,,Out,Out,,,,,In, 1189 messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,, 1191 securityModel,In,In,In,In,In,In,Out,In,In,In,, 1193 securityName,In,In,In,In,In,In,Out,In,Out,In,, 1195 securityLevel,In,In,In,In,In,In,Out,In,In,In,, 1197 contextEngineID,In,In,In,In,In,In,Out,,,,, 1199 contextName,In,In,In,In,In,In,Out,,,,, 1201 expectResponse,In,,,,In,,,,,,, 1203 PDU,In,In,In,In,In,In,Out,,,,, 1205 pduVersion,In,In,In,In,In,In,Out,,,,, 1207 statusInfo,Out,In,,In,,In,Out,Out,Out,Out,, 1209 errorIndication,Out,Out,,,,,Out,,,,, 1211 sendPduHandle,Out,,,In,In,,Out,,,,, 1213 maxSizeResponsePDU,,In,In,,,In,Out,,Out,,, 1215 stateReference,,In,In,,,In,Out,,,,, 1217 wholeMessage,,,,,Out,Out,In,Out,In,Out,In,In 1219 messageLength,,,,,Out,Out,In,Out,In,Out,In,In 1220 maxMessageSize,,,,,,,,In,In,In,, 1222 globalData,,,,,,,,In,,In,, 1224 securityEngineID,,,,,,,,In,Out,In,, 1226 scopedPDU,,,,,,,,In,Out,In,, 1228 securityParameters,,,,,,,,Out,In,Out,, 1230 securityStateReference,,,,,,,,,Out,In,, 1232 pduType,,,,,,,Out,,,,, 1234 tmStateReference,,,,,Out,Out,In,,In,,In,In 1236 Appendix B. Why tmStateReference? 1238 This appendix considers why a cache-based approach was selected for 1239 passing parameters. 1241 There are four approaches that could be used for passing information 1242 between the Transport Model and a Security Model. 1244 1. one could define an ASI to supplement the existing ASIs, or 1245 2. one could add a header to encapsulate the SNMP message, 1246 3. one could utilize fields already defined in the existing SNMPv3 1247 message, or 1248 4. one could pass the information in an implementation-specific 1249 cache or via a MIB module. 1251 B.1. Define an Abstract Service Interface 1253 Abstract Service Interfaces (ASIs) are defined by a set of primitives 1254 that specify the services provided and the abstract data elements 1255 that are to be passed when the services are invoked. Defining 1256 additional ASIs to pass the security and transport information from 1257 the Transport Subsystem to Security Subsystem has the advantage of 1258 being consistent with existing RFC3411/3412 practice, and helps to 1259 ensure that any Transport Model proposals pass the necessary data, 1260 and do not cause side effects by creating model-specific dependencies 1261 between itself and other models or other subsystems other than those 1262 that are clearly defined by an ASI. 1264 B.2. Using an Encapsulating Header 1266 A header could encapsulate the SNMP message to pass necessary 1267 information from the Transport Model to the dispatcher and then to a 1268 Message Processing Model. The message header would be included in 1269 the wholeMessage ASI parameter, and would be removed by a 1270 corresponding Message Processing Model. This would imply the (one 1271 and only) messaging dispatcher would need to be modified to determine 1272 which SNMP message version was involved, and a new Message Processing 1273 Model would need to be developed that knew how to extract the header 1274 from the message and pass it to the Security Model. 1276 B.3. Modifying Existing Fields in an SNMP Message 1278 [RFC3412] defines the SNMPv3 message, which contains fields to pass 1279 security related parameters. The Transport Subsystem could use these 1280 fields in an SNMPv3 message, or comparable fields in other message 1281 formats to pass information between Transport Models in different 1282 SNMP engines, and to pass information between a Transport Model and a 1283 corresponding Message Processing Model. 1285 If the fields in an incoming SNMPv3 message are changed by the 1286 Transport Model before passing it to the Security Model, then the 1287 Transport Model will need to decode the ASN.1 message, modify the 1288 fields, and re-encode the message in ASN.1 before passing the message 1289 on to the message dispatcher or to the transport layer. This would 1290 require an intimate knowledge of the message format and message 1291 versions so the Transport Model knew which fields could be modified. 1292 This would seriously violate the modularity of the architecture. 1294 B.4. Using a Cache 1296 This document describes a cache, into which the Transport Model puts 1297 information about the security applied to an incoming message, and a 1298 Security Model can extract that information from the cache. Given 1299 that there might be multiple TM-security caches, a tmStateReference 1300 is passed as an extra parameter in the ASIs between the Transport 1301 Subsystem and the Security Subsystem, so the Security Model knows 1302 which cache of information to consult. 1304 This approach does create dependencies between a specific Transport 1305 Model and a corresponding specific Security Model. However, the 1306 approach of passing a model-independent reference to a model- 1307 dependent cache is consistent with the securityStateReference already 1308 being passed around in the RFC3411 ASIs. 1310 Appendix C. Open Issues 1312 NOTE to RFC editor: If this section is empty, then please remove this 1313 open issues section before publishing this document as an RFC. (If 1314 it is not empty, please send it back to the editor to resolve. 1316 o MUST responses go back on the same transport session? How is this 1317 accomplished since the TM does not know pduType, and subsystems 1318 with knowledge of pdutype do not known about transport sessions. 1319 o Do Informs work correctly? 1321 Appendix D. Change Log 1323 NOTE to RFC editor: Please remove this change log before publishing 1324 this document as an RFC. 1326 Changes from -06- to -07- 1328 o Removed discussion of double authentication 1329 o Removed all direct and indirect references to pduType by Transport 1330 Subsystem 1331 o Added warning regarding keeping sensitive security informaiton 1332 available longer than needed. 1333 o Removed knowledge of securityStateReference from Transport 1334 Subsystem. 1335 o Changed transport session identifier to not include securityModel, 1336 since this is not known for incoming messages until the message 1337 processing model. 1339 Changes from revision -05- to -06- 1341 mostly editorial changes 1342 removed some paragraphs considered unnecessary 1343 added Updates to header 1344 modified some text to get the security details right 1345 modified text re: ASIs so they are not API-like 1346 cleaned up some diagrams 1347 cleaned up RFC2119 language 1348 added section numbers to citations to RFC3411 1349 removed gun for political correctness 1351 Changes from revision -04- to -05- 1353 removed all objects from the MIB module. 1354 changed document status to "Standard" rather than the xml2rfc 1355 default of informational. 1357 changed mention of MD5 to SHA 1358 moved addressing style to TDomain and TAddress 1359 modified the diagrams as requested 1360 removed the "layered stack" diagrams that compared USM and a 1361 Transport Model processing 1362 removed discussion of speculative features that might exist in 1363 future Transport Models 1364 removed openSession and closeSession ASIs, since those are model- 1365 dependent 1366 removed the MIB module 1367 removed the MIB boilerplate intro (this memo defines a SMIv2 MIB 1368 ...) 1369 removed IANA considerations related to the now-gone MIB module 1370 removed security considerations related to the MIB module 1371 removed references needed for the MIB module 1372 changed receiveMessage ASI to use origin transport domain/address 1373 updated Parameter CSV appendix 1374 Changes from revision -03- to -04- 1376 changed title from Transport Mapping Security Model Architectural 1377 Extension to Transport Subsystem 1378 modified the abstract and introduction 1379 changed TMSM to TMS 1380 changed MPSP to simply Security Model 1381 changed SMSP to simply Security Model 1382 changed TMSP to Transport Model 1383 removed MPSP and TMSP and SMSP from Acronyms section 1384 modified diagrams 1385 removed most references to dispatcher functionality 1386 worked to remove dependencies between transport and security 1387 models. 1388 defined snmpTransportModel enumeration similar to 1389 snmpSecurityModel, etc. 1390 eliminated all reference to SNMPv3 msgXXXX fields 1391 changed tmSessionReference back to tmStateReference 1393 Changes from revision -02- to -03- 1395 o removed session table from MIB module 1396 o removed sessionID from ASIs 1397 o reorganized to put ASI discussions in EOP section, as was done in 1398 SSHSM 1399 o changed user auth to client auth 1400 o changed tmStateReference to tmSessionReference 1401 o modified document to meet consensus positions published by JS 1402 o 1403 * authoritative is model-specific 1404 * msgSecurityParameters usage is model-specific 1405 * msgFlags vs. securityLevel is model/implementation-specific 1406 * notifications must be able to cause creation of a session 1407 * security considerations must be model-specific 1408 * TDomain and TAddress are model-specific 1409 * MPSP changed to SMSP (Security Model security processing) 1411 Changes from revision -01- to -02- 1413 o wrote text for session establishment requirements section. 1414 o wrote text for session maintenance requirements section. 1415 o removed section on relation to SNMPv2-MIB 1416 o updated MIB module to pass smilint 1417 o Added Structure of the MIB module, and other expected MIB-related 1418 sections. 1419 o updated author address 1420 o corrected spelling 1421 o removed msgFlags appendix 1422 o Removed section on implementation considerations. 1423 o started modifying the security boilerplate to address TMS and MIB 1424 security issues 1425 o reorganized slightly to better separate requirements from proposed 1426 solution. This probably needs additional work. 1427 o removed section with sample protocols and sample 1428 tmSessionReference. 1429 o Added section for acronyms 1430 o moved section comparing parameter passing techniques to appendix. 1431 o Removed section on notification requirements. 1433 Changes from revision -00- 1434 o changed SSH references from I-Ds to RFCs 1435 o removed parameters from tmSessionReference for DTLS that revealed 1436 lower layer info. 1437 o Added TMS-MIB module 1438 o Added Internet-Standard Management Framework boilerplate 1439 o Added Structure of the MIB Module 1440 o Added MIB security considerations boilerplate (to be completed) 1441 o Added IANA Considerations 1442 o Added ASI Parameter table 1443 o Added discussion of Sessions 1444 o Added Open issues and Change Log 1445 o Rearranged sections 1447 Authors' Addresses 1449 David Harrington 1450 Huawei Technologies (USA) 1451 1700 Alma Dr. Suite 100 1452 Plano, TX 75075 1453 USA 1455 Phone: +1 603 436 8634 1456 EMail: dharrington@huawei.com 1458 Juergen Schoenwaelder 1459 International University Bremen 1460 Campus Ring 1 1461 28725 Bremen 1462 Germany 1464 Phone: +49 421 200-3587 1465 EMail: j.schoenwaelder@iu-bremen.de 1467 Full Copyright Statement 1469 Copyright (C) The IETF Trust (2007). 1471 This document is subject to the rights, licenses and restrictions 1472 contained in BCP 78, and except as set forth therein, the authors 1473 retain all their rights. 1475 This document and the information contained herein are provided on an 1476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1478 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1479 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1480 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1483 Intellectual Property 1485 The IETF takes no position regarding the validity or scope of any 1486 Intellectual Property Rights or other rights that might be claimed to 1487 pertain to the implementation or use of the technology described in 1488 this document or the extent to which any license under such rights 1489 might or might not be available; nor does it represent that it has 1490 made any independent effort to identify any such rights. Information 1491 on the procedures with respect to rights in RFC documents can be 1492 found in BCP 78 and BCP 79. 1494 Copies of IPR disclosures made to the IETF Secretariat and any 1495 assurances of licenses to be made available, or the result of an 1496 attempt made to obtain a general license or permission for the use of 1497 such proprietary rights by implementers or users of this 1498 specification can be obtained from the IETF on-line IPR repository at 1499 http://www.ietf.org/ipr. 1501 The IETF invites any interested party to bring to its attention any 1502 copyrights, patents or patent applications, or other proprietary 1503 rights that may cover technology that may be required to implement 1504 this standard. Please address the information to the IETF at 1505 ietf-ipr@ietf.org. 1507 Acknowledgement 1509 Funding for the RFC Editor function is provided by the IETF 1510 Administrative Support Activity (IASA).