idnits 2.17.1 draft-ietf-isms-tmsm-00.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 on line 1612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1636. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 370 has weird spacing: '...patcher v ...' -- 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 (October 14, 2005) is 6768 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: 'RFC1510' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 1357, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 1365, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-secsh-connect' is defined on line 1400, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-secsh-transport' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-secsh-userauth' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'I-D.schoenw-snmp-tlsm' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 1432, but no explicit reference was found in the text == Unused Reference: 'RFC3413' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-ssh' is defined on line 1445, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-secsh-gsskeyex' is defined on line 1450, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Downref: Normative reference to an Experimental RFC: RFC 3430 ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. 'I-D.rescorla-dtls') -- Possible downref: Normative reference to a draft: ref. 'I-D.schoenw-snmp-tlsm' == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-09 == Outdated reference: A later version (-06) exists of draft-ietf-netconf-ssh-04 == Outdated reference: A later version (-14) exists of draft-ietf-tls-srp-10 Summary: 9 errors (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft Effective Software 4 Expires: April 17, 2006 J. Schoenwaelder 5 International University Bremen 6 October 14, 2005 8 Transport Mapping Security Model (TMSM) for the Simple Network 9 Management Protocol 10 draft-ietf-isms-tmsm-00.txt 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 April 17, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes a Transport Mapping Security Model (TMSM) for 44 the Simple Network Management Protocol (SNMP) architecture defined in 45 RFC 3411. This document identifies and discusses some key aspects 46 that need to be considered for any transport-mapping-based security 47 model for SNMP. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Requirements of a Transport Mapping Security Model . . . . . . 6 54 3.1. Security Requirements . . . . . . . . . . . . . . . . . . 6 55 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 6 56 3.2. Session Requirements . . . . . . . . . . . . . . . . . . . 7 57 3.3. Architectural Modularity Requirements . . . . . . . . . . 7 58 3.3.1. USM and the RFC3411 Architecture . . . . . . . . . . . 10 59 3.3.2. TMSM and the RFC3411 Architecture . . . . . . . . . . 11 60 3.4. Passing Messages between Subsystems . . . . . . . . . . . 12 61 3.5. Security Parameter Passing Requirement . . . . . . . . . . 13 62 3.5.1. Define an Abstract Service Interface . . . . . . . . . 14 63 3.5.2. Using an Encapsulating Header . . . . . . . . . . . . 14 64 3.5.3. Modifying Existing Fields in an SNMP Message . . . . . 15 65 3.5.4. Using a Cache . . . . . . . . . . . . . . . . . . . . 15 66 3.6. Architectural Requirements for Access Control . . . . . . 15 67 3.6.1. securityName Binding . . . . . . . . . . . . . . . . . 15 68 3.6.2. Separation of Authentication and Authorization . . . . 16 69 3.7. Requirements for Notifications . . . . . . . . . . . . . . 17 70 4. Scenario Diagrams . . . . . . . . . . . . . . . . . . . . . . 18 71 4.1. Command Generator or Notification Originator . . . . . . . 18 72 4.2. Command Responder . . . . . . . . . . . . . . . . . . . . 19 73 5. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 20 74 6. Integration with the SNMPv3 Message Format . . . . . . . . . . 21 75 6.1. msgVersion . . . . . . . . . . . . . . . . . . . . . . . . 21 76 6.2. msgGlobalData . . . . . . . . . . . . . . . . . . . . . . 21 77 6.3. securityLevel and msgFlags . . . . . . . . . . . . . . . . 22 78 6.4. The tmStateReference for Passing Security Parameters . . . 23 79 6.5. securityStateReference Cached Security Data . . . . . . . 23 80 6.5.1. Prepare an Outgoing SNMP Message . . . . . . . . . . . 24 81 6.5.2. Prepare Data Elements from an Incoming SNMP Message . 25 82 6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 83 7. Transport Mapping Security Model Samples . . . . . . . . . . . 26 84 7.1. TLS/TCP Transport Mapping Security Model . . . . . . . . . 26 85 7.1.1. tmStateReference for TLS . . . . . . . . . . . . . . . 26 86 7.1.2. MPSP for TLS TM-Security Model . . . . . . . . . . . . 27 87 7.1.3. MIB Module for TLS Security . . . . . . . . . . . . . 27 88 7.2. DTLS/UDP Transport Mapping Security Model . . . . . . . . 27 89 7.2.1. tmStateReference for DTLS . . . . . . . . . . . . . . 28 90 7.3. SASL Transport Mapping Security Model . . . . . . . . . . 29 91 7.3.1. tmStateReference for SASL DIGEST-MD5 . . . . . . . . 29 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 98 Appendix A. Questions about msgFlags: . . . . . . . . . . . . . . 33 99 A.1. msgFlags versus actual security . . . . . . . . . . . . . 33 100 A.2. Message security versus session security . . . . . . . . . 35 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 102 Intellectual Property and Copyright Statements . . . . . . . . . . 36 104 1. Introduction 106 This document describes the Transport Mapping Security Model (TMSM) 107 architectural extension for the Simple Network Management Protocol 108 (SNMP) architecture defined in [RFC3411]. This document identifies 109 and discusses some key aspects that need to be considered for any 110 transport-mapping-based security model for SNMP. 112 There are multiple ways to secure one's home or business, but they 113 largely boil down to a continuum of alternatives. Let's consider 114 three general approaches. In the first approach, an individual could 115 buy a gun, learn to use it, and sit on your front porch waiting for 116 intruders. In the second approach, one could hire an employee with a 117 gun, schedule the employee, position the employee to guard what you 118 want protected, hire a second guard to cover if the first gets sick, 119 and so on. In the third approach, you could hire a security company, 120 tell them what you want protected, and they could hire employees, 121 train them, buy the guns, position the guards, schedule the guards, 122 send a replacement when a guard cannot make it, etc., thus providing 123 the security you want, with no significant effort on your part other 124 than identifying requirements and verifying the quality of the 125 service being provided. 127 The User-based Security Model (USM) as defined in [RFC3414] largely 128 uses the first approach - it provides its own security. It utilizes 129 existing mechanisms (MD5=the gun), but provides all the coordination. 130 USM provides for the authentication of a principal, message 131 encryption, data integrity checking, timeliness checking, etc. 133 USM was designed to be independent of other existing security 134 infrastructures. USM therefore requires a separate user and key 135 management infrastructure. Operators have reported that deploying 136 another user and key management infrastructure in order to use SNMPv3 137 is a reason for not deploying SNMPv3 at this point in time. It is 138 possible but difficult to define external mechanisms that handle the 139 distribution of keys for use by the USM approach. 141 A solution based on the second approach might use a USM-compliant 142 architecture, but combine the authentication mechanism with an 143 external mechanism, such as RADIUS, to provide the authentication 144 service. It might be possible to utilize an external protocol to 145 encrypt a message, to check timeliness, to check data integrity, etc. 146 It is difficult to cobble together a number of subcontracted services 147 and coordinate them however, because it is difficult to build solid 148 security bindings between the various services, and potential for 149 gaps in the security is significant. 151 A solution based on the third approach might utilize one or more 152 lower-layer security mechanisms to provide the message-oriented 153 security services required. These would include authentication of 154 the sender, encryption, timeliness checking, and data integrity 155 checking. There are a number of IETF standards available or in 156 development to address these problems through security layers at the 157 transport layer or application layer, among them TLS [RFC2246], SASL 158 [RFC2222], and SSH [I-D.ietf-secsh-architecture]. 160 From an operational perspective, it is highly desirable to use 161 security mechanisms that can unify the administrative security 162 management for SNMPv3, command line interfaces (CLIs) and other 163 management interfaces. The use of security services provided by 164 lower layers is the approach commonly used for the CLI, and is also 165 the approach being proposed for NETCONF [I-D.ietf-netconf-prot]. 167 This document proposes a Transport Mapping Security Model (TMSM), as 168 an extension of the RFC3411 architecture, that allows security to be 169 provided by an external protocol connected to the SNMP engine through 170 an SNMP transport-mapping. Such a TMSM would then enable the use of 171 existing security mechanisms such as (TLS) [RFC2246] or SSH 172 [I-D.ietf-secsh-architecture] within the RFC3411 architecture. 174 There are a number of Internet security protocols and mechanisms that 175 are in wide spread use. Many of them try to provide a generic 176 infrastructure to be used by many different application layer 177 protocols. The motivation behind TMSM is to leverage these protocols 178 where it seems useful. 180 There are a number of challenges to be addressed to map the security 181 provided by a secure transport into the SNMP architecture so that 182 SNMP continues to work without any surprises. These challenges are 183 discussed in detail in this document. For some key issues, design 184 choices are discussed that may be made to provide a workable solution 185 that meets operational requirements and fits into the SNMP 186 architecture defined in [RFC3411] . 188 2. Conventions 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 Some points requiring further WG research and discussion are 195 identified by [todo] markers in the text. 197 3. Requirements of a Transport Mapping Security Model 199 3.1. Security Requirements 201 Transport mapping security protocols SHOULD ideally provide the 202 protection against the following message-oriented threats [RFC3411]: 204 1. modification of information 205 2. masquerade 206 3. message stream modification 207 4. disclosure 209 According to [RFC3411], it is not required to protect against denial 210 of service or traffic analysis. 212 3.1.1. Security Protocol Requirements 214 There are a number of standard protocols that could be proposed as 215 possible solutions within the TMSM framework. Some factors should be 216 considered when selecting a protocol for use within this framework. 218 Using a protocol in a manner for which it was not designed has 219 numerous problems. The advertised security characteristics of a 220 protocol may depend on its being used as designed; when used in other 221 ways, it may not deliver the expected security characteristics. It 222 is recommended that any proposed model include a discussion of the 223 applicability statement of the protocols to be used. 225 A protocol used for the TMSM framework should ideally require no 226 modifications to the protocol. Modifying the protocol may change its 227 security characteristics in ways that would impact other existing 228 usages. If a change is necessary, the change should be an extension 229 that has no impact on the existing usages. It is recommended that 230 any proposed model include a discussion of potential impact on other 231 usages of the protocol. 233 It has been a long-standing requirement that SNMP be able to work 234 when the network is unstable, to enable network troubleshooting and 235 repair. The UDP approach has been considered to meet that need well, 236 with an assumption that getting small messages through, even if out 237 of order, is better than gettting no messages through. There has 238 been a long debate about whether UDP actually offers better support 239 than TCP when the underlying IP or lower layers are unstable. There 240 has been recent discussion of whether operators actually use SNMP to 241 troubleshoot and repair unstable networks. 243 There has been discussion of ways SNMP could be extended to better 244 support management/monitoring needs when a network is running just 245 fine. Use of a TCP transport, for example, could enable larger 246 message sizes and more efficient table retrievals. 248 TMSM models MUST be able to coexist with other protocol models, and 249 may be designed to utilize either TCP or UDP, depending on the 250 transport. 252 3.2. Session Requirements 254 Sessions are not part of the SNMP architecture, but are considered 255 desirable because the cost of authentication can be amortized over 256 potentially many transactions. 258 For transports that utilize sessions, a session should have a single 259 user and security level associated with it. If an exchange between 260 communicating engines would require a different security level or 261 would be on behalf of a different user, then another session would be 262 needed. An immediate consequence of this is that implementations 263 should be able to maintain some reasonable number of concurrent 264 sessions. 266 [todo] Say more about how sessions are initiated, how session state 267 is made visibile and so on. 269 3.3. Architectural Modularity Requirements 271 SNMP version 3 (SNMPv3) is based on a modular architecture (described 272 in [RFC3411] section 3) to allow the evolution of the SNMP protocol 273 standards over time, and to minimize side effects between subsystems 274 when changes are made. This architecture includes a Security 275 Subsystem which is responsible for realizing security services. 277 In SNMPv2, there were many problems of side effects between 278 subsystems caused by the manipulation of MIB objects, especially 279 those related to authentication and authorization, because many of 280 the parameters were stored in shared MIB objects, and different 281 models and protocols could assign different values to the objects. 282 Contributors assumed slightly different shades of meaning depending 283 on the models and protocols being used. As the shared MIB module 284 design was modified to accommodate a specific model, other models 285 which used the same MIB objects were broken. 287 Abstract Service Interfaces (ASIs) were developed to pass model- 288 independent parameters. The models were required to translate from 289 their model-dependent formats into a model-independent format, 290 defined using model-independent semantics, which would not impact 291 other models. 293 Parameters have been provided in the ASIs to pass model-independent 294 information about the authentication that has been provided. These 295 parameters include a model-independent identifier of the security 296 "principal", the security model used to perform the authentication, 297 and which SNMP-specific security features were applied to the message 298 (authentication and/or privacy). 300 The design of a transport mapping security model must abide the goals 301 of the RFC3411 architecture defined in [RFC3411]. To that end, this 302 transport mapping security model proposal focuses on a modular 303 subsystem that can be advanced through the standards process 304 independently of other proposals, and independent of other subsystems 305 as much as possible. 307 There has been some discussion of maintaining multiple sessions for 308 different security levels or for different applications. The ability 309 to have an application select different sessions or connections on a 310 per-message basis would likely require a modification to the SNMP 311 architecture to provide new ASIs, which is out of scope for this 312 document. 314 [todo] I am not sure whether the previous paragraph is still correct 315 - I think we need to solve at least some of the session problem 316 space. 318 IETF standards typically require one mandatory-to-implement solution, 319 with the capability of adding new security mechanisms in the future. 320 Any transport mapping security model should define one minimum- 321 compliance mechanism, preferably one which is already widely deployed 322 within the transport layer security protocol used. 324 The TMSM subsystem is designed as an architectural extension that 325 permits additional transport security protocols to be "plugged into" 326 the RFC3411 architecture, supported by corresponding transport- 327 security-aware transport mapping models. 329 The RFC3411 architecture, and the USM approach, assume that a 330 security model is called by a message-processing model and will 331 perform multiple security functions. The TMSM approach performs 332 similar functions but performs them in different places within the 333 archtitecture, so we need to distinguish the two locations for 334 security processing. 336 Transport mapping security is by its very nature a security layer 337 which is plugged into the RFC3411 architecture between the transport 338 layer and the message dispatcher. Conceptually, transport mapping 339 security processing will be called from within the Transport Mapping 340 functionality of an SNMP engine dispatcher to perform the translation 341 of transport security parameters to/from security-model-independent 342 parameters. This transport mapping security processor will be 343 referred to in this document as TMSP. 345 Additional functionality may be performed as part of the message 346 processing function, i.e. in the security subsystem of the RFC3411 347 architecture. This document will refer to message processor's 348 security processor as the MPSP. 350 Thus a TMSM is composed of both a TPSP and an MPSP. 352 +------------------------------+ 353 | Network | 354 +------------------------------+ 355 ^ ^ ^ 356 | | | 357 v v v 358 +-----+ +-----+ +-------+ 359 | UDP | | TCP | . . . | other | 360 +-----+ +-----+ +-------+ 361 ^ ^ ^ 362 | | | 363 v v v 364 +-----+ +-----+ +-------+ 365 | SSH | | TLS | . . . | other | 366 +-----+ +-----+ +-------+ (traditional SNMP agent) 367 +-------------------------------------------------------------------+ 368 | ^ | 369 | | | 370 | Dispatcher v | 371 | +-------------------+ | 372 | | Transport | +--------------+ | 373 | | Mapping |<---> | TMSM | | 374 | | (e.g., RFC 3417) | | TMSP | | 375 | | | +--------------+ | 376 | | | | 377 | | | +---------------------+ +----------------+ | 378 | | | | Message Processing | | Security | | 379 | | | | Subsystem | | Subsystem | | 380 | | | | +------------+ | | | | 381 | | | | +->| v1MP * |<--->| +------------+ | | 382 | | | | | +------------+ | | | Other | | | 383 | | | | | +------------+ | | | Security | | | 384 | | | | +->| v2cMP * |<--->| | Model | | | 385 | | Message | | | +------------+ | | +------------+ | | 386 | | Dispatcher <--------->| +------------+ | | +------------+ | | 387 | | | | +->| v3MP * |<--->| | TMSM | | | 388 | | | | | +------------+ | | | MPSP | | | 389 | | PDU Dispatcher | | | +------------+ | | | | | | 390 | +-------------------+ | +->| otherMP * |<--->| +------------+ | | 391 | ^ | +------------+ | | | | 392 | | +---------------------+ +----------------+ | 393 | v | 394 | +-------+-------------------------+---------------+ | 395 | ^ ^ ^ | 396 | | | | | 397 | v v v | 398 | +-------------+ +---------+ +--------------+ +-------------+ | 399 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 400 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 401 | | application | | | | applications | | application | | 402 | +-------------+ +---------+ +--------------+ +-------------+ | 403 | ^ ^ | 404 | | | | 405 | v v | 406 | +----------------------------------------------+ | 407 | | MIB instrumentation | SNMP entity | 408 +-------------------------------------------------------------------+ 410 3.3.1. USM and the RFC3411 Architecture 412 The following diagrams illustrate the difference in the security 413 processing done by the USM model and the security processing done by 414 a TMSM model. 416 The USM security model is encapsulated by the messaging model, 417 because the messaging model needs to perform the following steps (for 418 incoming messages) 419 1) decode the ASN.1 (messaging model) 420 2) determine the SNMP security model and parameters (messaging model) 421 3) decrypt the encrypted portions of the message (security model) 422 4) translate parameters to model-independent parameters (security 423 model) 424 5) determine which application should get the decrypted portions 425 (messaging model), and 426 6) pass on the decrypted portions with model-independent parameters. 428 The USM approach uses SNMP-specific message security and parameters. 430 | -----------------------------------------------| 431 | transport layer | 432 | -----------------------------------------------| 433 ^ 434 | 435 v 436 -------------------------------------------------- 437 | -----------------------------------------------| 438 | | transport mapping | 439 | -----------------------------------------------| 440 | ^ 441 | | 442 | v 443 | --------------------------------------------- | 444 | --------------------- ------------------ | 445 | SNMP messaging <--> | decryption + | | 446 | | translation | | 447 | --------------------- ------------------ | 448 | ^ 449 | | 450 | v 451 | --------------------- ------------------ | 452 | | SNMP applications | <--> | access control | | 453 | --------------------- ------------------ | 455 | --------------------------------------------- | 457 3.3.2. TMSM and the RFC3411 Architecture 459 In the TMSM approach, the order of the steps differ and may be 460 handled by different subsystems: 461 1) decrypt the encrypted portions of the message (transport layer) 462 2) determine the SNMP security model and parameters (transport 463 mapping) 464 3*) translate parameters to model-independent parameters (transport 465 mapping) 466 4) decode the ASN.1 (messaging model) 467 5) determine which application should get the decrypted portions 468 (messaging model) 469 6*) translate parameters to model-independent parameters (security 470 model) 471 7) pass on the decrypted portions with model-independent security 472 parameters 474 This is largely based on having non-SNMP-specific message security 475 and parameters. The transport mapping model might provide the 476 translation from e.g., an SSH user name to the securityName in step 477 3, OR the SSH user might be passed to the messaging model to pass to 478 a TMSM security model to do the translation in step 6, if the WG 479 decides all translations should use the same translation table (e.g., 480 the USM MIB). 482 | -----------------------------------------------| 483 | ------------------ | 484 | transport layer <--> | decryption | | 485 | ------------------ | 486 | -----------------------------------------------| 487 ^ 488 | 489 v 490 -------------------------------------------------- 491 | -----------------------------------------------| 492 | ------------------ | 493 | transport mapping <--> | translation* | | 494 | ------------------ | 495 | -----------------------------------------------| 496 | ^ 497 | | 498 | v 499 | --------------------------------------------- | 500 | ------------------ | 501 | SNMP messaging <--> | translation* | | 502 | ------------------ | 503 | --------------------- ------------------ | 504 | ^ 505 | | 506 | v 507 | --------------------- ------------------ | 508 | | SNMP applications | <--> | access control | | 509 | --------------------- ------------------ | 511 | --------------------------------------------- | 513 3.4. Passing Messages between Subsystems 515 RFC3411 defines ASIs that describe the passing of messages between 516 subsystem within an engine, and the parameters which are expected to 517 be passed between the subsystems. The ASIs generally pass model- 518 independent information. 520 A TMSM model will establish an encrypted tunnel between the transport 521 mappings of two SNMP engines. One transport mapping security model 522 instance encrypts all messages, and the other transport mapping 523 security model instance decrypts the messages. 525 After the transport layer tunnel is established, then SNMP messages 526 can conceptually be sent through the tunnel from one SNMP message 527 dispatcher to another SNMP message dispatcher. Once the tunnel is 528 established, multiple SNMP messages may be able to be passed through 529 the same tunnel. 531 Within an engine, outgoing SNMP messages are passed unencrypted from 532 the message dispatcher to the transport mapping, and incoming 533 messages are passed unencrypted from the transport mapping to the 534 message dispatcher. 536 3.5. Security Parameter Passing Requirement 538 RFC3411 section 4 describes primitives to describe the abstract 539 service interfaces used to conceptually pass information between the 540 various subsystems, models and applications within the architecture. 542 The security parameters include a model-independent identifier of the 543 security "principal", the security model used to perform the 544 authentication, and which SNMP-specific security services were 545 (should be) applied to the message (authentication and/or privacy). 547 In the RFC3411 architecture, the messaging model must unpack SNMP- 548 specific security parameters from the message before calling a 549 security model to authenticate and decrypt an incoming message, 550 perform integrity checking, and translate model-specific security 551 parameters into model-independent parameters. In the TMSM approach, 552 the security-model specific parameters are not all carried in the 553 SNMP message, and can be determined from the transport layer by the 554 transport mapping, before the message processing begins. 556 [todo] For outgoing messages, it is necessary to have an MPSP because 557 it is the MPSP that actually creates the message from it scomponent 558 parts. Does the MPSP need to know the transport address or the 559 actual transport security capabilities, or can this be handled in the 560 TMSP, given the model-independent (and message-version-independent) 561 parameters? Are there any security services provided by the MPSP for 562 an outgoing message? 564 [todo] For incoming messages, is there security functionality that 565 can only be handled after the message version is known, such as the 566 comparison of transport security capabilities and msgFlags? Does 567 that functionality need to know the transport address and session or 568 just the model-independent security parameters (securityName, model, 569 level)? Are there any SNMP-specific parameters that need to be 570 unpacked from the message for MPSP handling? msgFlags, securityLevel, 571 etc.? 573 The RFC3411 architecture has no ASI parameters for passing security 574 information between the transport mapping and the dispatcher, and 575 between the dispatcher and the message processing model. If there is 576 a need to have an MPSP called from the message processing model to, 577 for example, verify that msgFlags and the transport security are 578 consistent, then it will be necessary to pass the model-independent 579 security parameters from the TPSP through to the MPSP. 581 There are four approaches that could be used for passing information 582 between the TMSP and an MPSP. 583 1. one could define an ASI to supplement the existing ASIs, or 584 2. the TMSM could add a header to encapsulate the SNMP message, 585 3. the TMSM could utilize fields already defined in the existing 586 SNMPv3 message, or 587 4. the TMSM could pass the information in an implementation-specific 588 cache or via a MIB module. 590 3.5.1. Define an Abstract Service Interface 592 Abstract Service Interfaces (ASIs) [RFC3411] are defined by a set of 593 primitives that specify the services provided and the abstract data 594 elements that are to be passed when the services are invoked. 595 Defining additional ASIs to pass the security and transport 596 information from the transport mapping to a messaging security model 597 has the advantage of being consistent with existing RFC3411/3412 598 practice, and helps to ensure that any TMSM proposals pass the 599 necessary data, and do not cause side effects by creating model- 600 specific dependencies between itself and other models or other 601 subsystems other than those that are clearly defined by an ASI. 603 3.5.2. Using an Encapsulating Header 605 A header could encapsulate the SNMP message to pass necessary 606 information from the TMSP to the dispatcher and then to a messaging 607 security model. The message header would be included in the 608 wholeMessage ASI parameter, and would be removed by a corresponding 609 messaging model. This would imply the (one and only) messaging 610 dispatcher would need to be modified to determine which SNMP message 611 version was involved, and a new message processing model would need 612 to be developed that knew how to extract the header from the message 613 and pass it to the MPSP. 615 3.5.3. Modifying Existing Fields in an SNMP Message 617 [RFC3412] describes the SNMPv3 message, which contains fields to pass 618 security related parameters. The TMSM could use these fields in an 619 SNMPv3 message, or comparable fields in other message formats to pass 620 information between transport mapping security models in different 621 SNMP engines, and to pass information between a transport mapping 622 security model and a corresponding messaging security model. 624 If the fields in an incoming SNMPv3 message are changed by the TMSP 625 before passing it to the MPSP, then the TMSP will need to decode the 626 ASN.1 message, modify the fields, and re-encode the message in ASN.1 627 before passing the message on to the message dispatcher or to the 628 transport layer. This would require an intimate knowledge of the 629 message format and message versions so the TMSP knew which fields 630 could be modified. This would seriously violate the modularity of 631 the architecture. 633 3.5.4. Using a Cache 635 A cache mechanism could be used, into which the TMSP puts information 636 about the security applied to an incoming message, and an MPSP 637 extracts that information from the cache. Given that there may be 638 multiple TM-security caches, a cache ID would need to be passed 639 through an ASI so the MPSP knows which cache of information to 640 consult. 642 The cache reference could be thought of as an additional parameter in 643 the ASIs between the transport mapping and the messaging security 644 model. The RFC3411 ASIs would not need to be changed since the 645 SNMPv3 WG expected that additional parameters could be passed for 646 value-add features of specific implementations. 648 This approach does create dependencies between a model-specific TPSP 649 and a corresponding specific MPSP. If a TMSM-model-independent ASI 650 parameter is passed, this approach would be consistent with the 651 securityStateReference cache already being passed around in the ASI. 653 This document will describe a cache-based approach. 655 3.6. Architectural Requirements for Access Control 657 3.6.1. securityName Binding 659 For SNMP access control to function properly, the security mechanism 660 must establish a securityModel identifier, a securityLevel, and a 661 securityName, which is the security model independent identifier for 662 a principal. The SNMPv3 message processing architecture subsystem 663 relies on a security model, such as USM, to play a role in security 664 that goes beyond protecting the message - it provides a mapping 665 between the USM-specific principal to a security-model independent 666 securityName which can be used for subsequent processing, such as for 667 access control. 669 The TMSM is a two-stage security model, with a transport mapping 670 security process (TMSP) and a message processing security process 671 (MPSP). Depending on the design of the specific TMSM model, i.e. 672 which transport layer protocol is used, different features might be 673 provided by the TMSP or by the MPSP. For example, the translation 674 from a mechanism-specific authenticated identity to a securityName 675 might be done by the TMSP or by the MPSP. 677 [todo] It may be possible to define a consistent division of stages 678 regardless of the transport layer protocol used, and a consistent 679 division of functionality would be preferred. 681 The SNMP architecture distinguishes between messages with no 682 authentication and no privacy (noAuthNoPriv), authentication without 683 privacy (authNoPriv) and authentication with privacy (authPriv). 684 Hence, the authentication of a transport layer identity plays an 685 important role and must be considered by any TMSM, and user 686 authentication must be available via the transport layer security 687 protocol. 689 If the type of authentication provided by the transport layer (e.g. 690 host-based or anonymous) is considered adequate to secure and/or 691 encrypt the message, but inadequate to provide the desired 692 granularity of access control (e.g. user-based), a second 693 authentication, e.g. one provided by a AAA server, may be used to 694 provide the authentication identity which is bound to the 695 securityName. This approach would require a good analysis of the 696 potential for man-in-the-middle attacks or masquerade possibilities. 698 3.6.2. Separation of Authentication and Authorization 700 A TMSM security model should take care to not violate the separation 701 of authentication and authorization in the RFC3411 architecture.. 702 The isAccessAllowed() primitive is used for passing security-model 703 independent parameters between the subsystems of the architecture. 705 Mapping of (securityModel, securityName) to an access control policy 706 should be handled within the access control subsystem, not the 707 security subsystem, to be consistent with the modularity of the 708 RFC3411 architecture. This separation was a deliberate decision of 709 the SNMPv3 WG, to allow support for authentication protocols which 710 did not provide authorization capabilities, and to support 711 authorization schemes, such as VACM, that do not perform their own 712 authentication. 714 An authorization model MAY require authentication by certain 715 securityModels and a minimum securityLevel to allow access to the 716 data. 718 TMSM is an enhancement for the SNMPv3 privacy and authentication 719 provisions, but it is not a significant improvement for the 720 authorization needs of SNMPv3. TMSM provides all the model- 721 independent parameters for the isAccessAllowed() primitive [RFC3411]. 723 TMSM does not specify how the securityModel and securityName could be 724 dynamically mapped to a VACM-style groupName. The mapping of 725 (securityModel, securityName) to a groupName is a VACM-specific 726 mechanism for naming an access control policy, and for tying the 727 named policy to the addressing capabilities of the data modeling 728 language (e.g. SMIv2), the operations supported, and other factors. 729 Providing a binding outside the Access Control subsystem might create 730 dependencies that could make it harder to develop alternate models of 731 access control, such as one built on UNIX groups, Windows domains, 732 XML hierarchies, or task-based controls. The preferred approach is 733 to pass the model-independent security parameters via the 734 isAccessAllowed() ASI, and perform the mapping within the access 735 control model. 737 To provide support for protocols which simultaneously send 738 information for authentication and authorization, such as RADIUS, 739 model-specific authorization information MAY be cached or otherwise 740 made available to the access control subsystem, e.g. via a MIB table 741 similar to the vacmSecurityToGroupTable, so the access control 742 subsystem can create an approrpiate binding between the model- 743 independent securityModel and securityName and a model-specific 744 access control policy. This may be highly undesirable, however, if 745 it creates a dependency between a security model and an access 746 control model, just as it is undesirable that the TMSM approach 747 creates a dependency between a TMSP and an MPSP. 749 3.7. Requirements for Notifications 751 [todo] cleanup this section 753 RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated 754 by notification originators in case there is no currently established 755 connection that can be used to send the notification. Following this 756 approach with SSH would require to provision authentication 757 credentials on the agent so that agents can successfully authenticate 758 to a notification receiver. There might be other approaches, like 759 the reuse of manager initiated secure transport connections for 760 notifications. There is some text in Appendix A in RFC 3430 which 761 captures some of these discussions when RFC 3430 was written. 763 [todo] merge this text and text from RFC 3430 into the section 764 dealing with sessions? This seems to be the right place for this 765 discussion. 767 4. Scenario Diagrams 769 RFC3411 section 4.6 provides scenario diagrams to illustrate how an 770 outgoing message is created, and how an incoming message is 771 processed. Both diagrams are incomplete, however.In section 4.61, 772 the diagram doesn't show the ASI for sending an SNMP request to the 773 network or receiving an SNMP response message from the network. In 774 section 4.6.2, the diagram doesn't illustrate the interfaces required 775 to receive an SNMP message from the network, or to send an SNMP 776 message to the network. 778 4.1. Command Generator or Notification Originator 780 This diagram from RFC3411 4.6.1 shows how a Command Generator or 781 Notification Originator application requests that a PDU be sent, and 782 how the response is returned (asynchronously) to that application. 784 Command Dispatcher Message Security 785 Generator | Processing Model 786 | | Model | 787 | sendPdu | | | 788 |------------------->| | | 789 | | prepareOutgoingMessage | | 790 : |----------------------->| | 791 : | | generateRequestMsg | 792 : | |-------------------->| 793 : | | | 794 : | |<--------------------| 795 : | | | 796 : |<-----------------------| | 797 : | | | 798 : |------------------+ | | 799 : | Send SNMP | | | 800 : | Request Message | | | 801 : | to Network | | | 802 : | v | | 803 : : : : : 804 : : : : : 805 : : : : : 806 : | | | | 807 : | Receive SNMP | | | 808 : | Response Message | | | 809 : | from Network | | | 810 : |<-----------------+ | | 811 : | | | 812 : | prepareDataElements | | 813 : |----------------------->| | 814 : | | processIncomingMsg | 815 : | |-------------------->| 816 : | | | 817 : | |<--------------------| 818 : | | | 819 : |<-----------------------| | 820 | processResponsePdu | | | 821 |<-------------------| | | 822 | | | | 824 4.2. Command Responder 826 This diagram shows how a Command Responder or Notification Receiver 827 application registers for handling a pduType, how a PDU is dispatched 828 to the application after an SNMP message is received, and how the 829 Response is (asynchronously) send back to the network. 831 Command Dispatcher Message Security 832 Responder | Processing Model 833 | | Model | 834 | | | | 835 | registerContextEngineID | | | 836 |------------------------>| | | 837 |<------------------------| | | | 838 | | Receive SNMP | | | 839 : | Message | | | 840 : | from Network | | | 841 : |<-------------+ | | 842 : | | | 843 : |prepareDataElements | | 844 : |------------------->| | 845 : | | processIncomingMsg | 846 : | |------------------->| 847 : | | | 848 : | |<-------------------| 849 : | | | 850 : |<-------------------| | 851 | processPdu | | | 852 |<------------------------| | | 853 | | | | 854 : : : : 855 : : : : 856 | returnResponsePdu | | | 857 |------------------------>| | | 858 : | prepareResponseMsg | | 859 : |------------------->| | 860 : | |generateResponseMsg | 861 : | |------------------->| 862 : | | | 863 : | |<-------------------| 864 : | | | 865 : |<-------------------| | 866 : | | | 867 : |--------------+ | | 868 : | Send SNMP | | | 869 : | Message | | | 870 : | to Network | | | 871 : | v | | 873 5. Abstract Service Interfaces 875 The OUT parameters of the prepareOutgoingMessage() ASI are used to 876 pass information from the message processing model to the dispatcher 877 and on to the transport mapping: 879 statusInformation = -- success or errorIndication 880 prepareOutgoingMessage( 881 IN transportDomain -- transport domain to be used 882 IN transportAddress -- transport address to be used 883 IN messageProcessingModel -- typically, SNMP version 884 IN securityModel -- Security Model to use 885 IN securityName -- on behalf of this principal 886 IN securityLevel -- Level of Security requested 887 IN contextEngineID -- data from/at this entity 888 IN contextName -- data from/in this context 889 IN pduVersion -- the version of the PDU 890 IN PDU -- SNMP Protocol Data Unit 891 IN expectResponse -- TRUE or FALSE 892 IN sendPduHandle -- the handle for matching 893 -- incoming responses 894 OUT destTransportDomain -- destination transport domain 895 OUT destTransportAddress -- destination transport address 896 OUT outgoingMessage -- the message to send 897 OUT outgoingMessageLength -- its length 898 ) 900 6. Integration with the SNMPv3 Message Format 902 TMSM proposals can use the SNMPv3 message format, defined in RFC3412, 903 section 6. This seection discusses how the fields could be reused. 905 6.1. msgVersion 907 For proposals that reuse the SNMPv3 message format, this field should 908 contain the value 3. 910 6.2. msgGlobalData 912 The fields msgID and msgMaxSize are used identically for the TMSM 913 models as for the USM model. 915 The msgSecurityModel field should be set to a value from the 916 SnmpSecurityModel enumeration [RFC3411] to identify the specific TMSM 917 model. Each standards-track TMSM model should have an enumeration 918 assigned by IANA. Each enterprise-specific security model should 919 have an enumeration assigned following instructions in the 920 description of the SnmpSecurityModel TEXTUAL-CONVENTION from RFC3411. 922 The msgSecurityParameters field would carry security information 923 required for message security processing. It is unclear whether this 924 field would be useful or what parameters would be carried to support 925 security, since message security is provided by an external process, 926 and msgSecurityParameters are not used by the access control 927 subsystem. 929 RFC3412 defines two primitives, generateRequestMsg() and 930 processIncomingMsg() which require the specification of an 931 authoritative SNMP entity. [todo] We need to discuss what the meaning 932 of authoritative would be in a TMSM environment, whether the specific 933 services provided in USM security from msgSecurityParameters still 934 are needed, and how the Message Processing model provides this 935 information to the security model via generateRequestMsg() and 936 processIncomingMsg() primitives. RFC3412 specifies that "The data in 937 the msgSecurityParameters field is used exclusively by the Security 938 Model, and the contents and format of the data is defined by the 939 Security Model. This OCTET STRING is not interpreted by the v3MP, 940 but is passed to the local implementation of the Security Model 941 indicated by the msgSecurityModel field in the message." 943 The msgFlags have the same values for the TMSM models as for the USM 944 model. "The authFlag and privFlag fields indicate the securityLevel 945 that was applied to the message before it was sent on the wire." 947 6.3. securityLevel and msgFlags 949 For an outgoing message, msgFlags is the requested security for the 950 message; if a TMSM cannot provide the requested securityLevel, the 951 model MUST describe a standard behavior that is followed for that 952 situation. If the TMSM cannot provide at least the requested level 953 of security, the TMSM MUST discard the request and SHOULD notify the 954 message processing model that the request failed. 956 [todo] how is yet to be determined, and may be model-specific or 957 implementation-specific. 959 For an outgoing message, if the TMSM is able to provide stronger than 960 requested security, that may be acceptable. The transport layer 961 protocol would need to indicate to the receiver what security has 962 been applied to the actual message. To avoid the need to mess with 963 the ASN.1 encoding, the SNMPv3 message carries the requested 964 msgFlags, not the actual securityLevel applied to the message. If a 965 message format other than SNMPv3 is used, then the new message may 966 carry the more accurate securityLevel in the SNMP message. 968 For an incoming message, the receiving TMSM knows what must be done 969 to process the message based on the transport layer mechanisms. If 970 the underlying transport security mechanisms for the receiver cannot 971 provide the matching securityLevel, then the message should follow 972 the standard behaviors for the transport security mechanism, or be 973 discarded silently. 975 Part of the responsibility of the TMSM is to ensure that the actual 976 security provided by the underlying transport layer security 977 mechanisms is configured to meet or exceed the securityLevel required 978 by the msgFlags in the SNMP message. When the MPSP processes the 979 incoming message, it should compare the msgFlags field to the 980 securityLevel actually provided for the message by the transport 981 layer security. If they differ, the MPSP should determine whether 982 the changed securityLevel is acceptable. If not, it should discard 983 the message. Depending on the model, the MPSP may issue a reportPDU 984 with the XXXXXXX model-specific counter. 986 6.4. The tmStateReference for Passing Security Parameters 988 A tmStateReference is used to pass data between the TMSP and the 989 MPSP, similar to the securityStateReference described in RFC3412. 990 This can be envisioned as being appended to the ASIs between the TM 991 and the MP or as being passed in an encapsulating header. 993 The TMSP may provide only some aspects of security, and leave some 994 aspects to the MPSP. tmStateReference should be used to pass any 995 parameters, in a model- and mechanism-specific format, that will be 996 needed to coordinate the activities of the TMSP and MPSP, and the 997 parameters subsequently passed in securityStateReference. For 998 example, the TMSP may provide privacy and data integrity and 999 authentication and authorization policy retrievals, or some subset of 1000 these features, depending on the features available in the transport 1001 mechanisms. A field in tmStateReference should identify which 1002 services were provided for each received message by the TMSP, the 1003 securityLevel applied to the received message, the model-specific 1004 security identity, the session identifier for session based transport 1005 security, and so on. 1007 6.5. securityStateReference Cached Security Data 1009 From RFC3411: "For each message received, the Security Model caches 1010 the state information such that a Response message can be generated 1011 using the same security information, even if the Local Configuration 1012 Datastore is altered between the time of the incoming request and the 1013 outgoing response. 1015 A Message Processing Model has the responsibility for explicitly 1016 releasing the cached data if such data is no longer needed. To 1017 enable this, an abstract securityStateReference data element is 1018 passed from the Security Model to the Message Processing Model. The 1019 cached security data may be implicitly released via the generation of 1020 a response, or explicitly released by using the stateRelease 1021 primitive, as described in RFC3411 section 4.5.1." 1023 For the TMSM approach, the TMSP may need to provide information to 1024 the message processing model, such as the security-model-independent 1025 securityName, securityLevel, and securityModel parameters, and for 1026 responses, the messaging model may need to pass the parameters back 1027 to the TMSP. To differentiate what information needs to be provided 1028 to the message processing model by the TMSP, and vice-versa, this 1029 document will differentiate the tmStateReference provide by the TMSP 1030 from the securityStateReference provided by the MPSP. An 1031 implementation MAY use one cache and one reference to serve both 1032 functions, but an implementor must be aware of the cache-release 1033 issues to prevent the cache from being released before the transport 1034 mapping has had an opportunity to extract the information it needs. 1036 6.5.1. Prepare an Outgoing SNMP Message 1038 Following RFC3412, section 7.1, the SNMPv3 message processing model 1039 uses the generateResponseMsg() or generateRequestMsg() primitives, to 1040 call the MPSP. The message processing model, or the MPSP it calls, 1041 may need to put information into the tmStateReference cache for use 1042 by the TMSP, such as: 1043 tmSecurityStateReference - the unique identifier for the cached 1044 information 1045 tmTransportDomain 1046 tmTransportAddress 1047 tmSecurityModel - an indicator of which mechanisms to use 1048 tmSecurityName - a model-specific identifier of the security 1049 principal 1050 tmSecurityLevel - an indicator of which security services are 1051 requested 1052 and may contain additional information such as 1053 tmSessionID 1054 tmSessionKey 1055 tmSessionMsgID 1057 According to RFC3411, section 4.1.1, the application provides the 1058 transportDomain and transportAddress to the PDU dispatcher via the 1059 sendPDU() primitive. If we permit multiple sessions per 1060 transportAddress, then we would need to define how session 1061 identifiers get passed from the application to the PDU dispatcher 1062 (and then to the MP model). 1064 The SNMP over TCP Transport Mapping document [RFC3430] says that TCP 1065 connections can be recreated dynamically or kept for future use and 1066 actually leaves all that to the transport mapping. 1068 [todo] we might define a new transportDomain and transportAddress, 1069 which includes the address and session identifier. For situations 1070 where a session has not yet been established, we could pass a 0x0000 1071 session identifier (or whatever) to indicate that a session should be 1072 established. Well, this won't work with the current TAddress 1073 definitions and is probably too ugly to do. 1075 We might have a MIB module that records the session information for 1076 subsequent use by the applications and other subsytems, or it might 1077 be passed in the tmStateReference cache. For notifications, I assume 1078 the SNMPv3 notification tables would be a place to find the address, 1079 but I'm not sure how to identify the presumably-dynamic session 1080 identifiers. The MIB module could identify whether the session was 1081 initiated by the remote engine or initiated by the current engine, 1082 and possibly assigned a purpose (incoming request/response or 1083 outgoing notifications). First we need to decide whether to handle 1084 notifications and requests in one or two (or more) sessions, which 1085 might depend on the transport protocol we choose (the same problem 1086 netconf faced). 1088 6.5.2. Prepare Data Elements from an Incoming SNMP Message 1090 For an incoming message, the TMSP will need to put information from 1091 the transport mechanisms used into the tmStateReference so the MPSP 1092 can extract the information and add it conceptually to the 1093 securityStateReference. 1095 The tmStateReference cache will likely contain at least the following 1096 information: 1097 tmStateReference - a unique identifier for the cached information 1098 tmSecurityStateReference - the unique identifier for the cached 1099 information 1100 tmTransportDomain 1101 tmTransportAddress 1102 tmSecurityModel - an indicator of which mechanisms to use 1103 tmSecurityName - a model-specific identifier of the security 1104 principal 1105 tmSecurityLevel - an indicator of which security services are 1106 requested 1107 tmAuthProtocol 1108 tmPrivProtocol 1109 and may contain additional information such as 1110 tmSessionID 1111 tmSessionKey 1112 tmSessionMsgID 1114 6.6. Notifications 1116 For notifications, if the cache has been released and then session 1117 closed, then the MPSP will request the TMSP to establish a session, 1118 populate the cache, and pass the securityStateReference to the MPSP. 1120 [todo] We need to determine what state needs to be saved here. 1122 7. Transport Mapping Security Model Samples 1124 There are a number of standard protocols that could be proposed as 1125 possible solutions within the TMSM framework. Some factors should be 1126 considered when selecting a protocol for use within this framework. 1128 Using a protocol in a manner for which is was not designed has 1129 numerous problems. The advertised security characteristics of a 1130 protocol may depend on its being used as designed; when used in other 1131 ways, it may not deliver the expected security characteristics. It 1132 is recommended that any proposed model include a discussion of the 1133 applicability statement of the protocols to be used. 1135 7.1. TLS/TCP Transport Mapping Security Model 1137 SNMP supports multiple transports. The preferred transport for SNMP 1138 over IP is UDP [RFC3417]. An experimental transport for SNMP over 1139 TCP is defined in [RFC3430]. 1141 TLS/TCP will create an association between the TMSM of one SNMP 1142 entity and the TMSM of another SNMP entity. The created "tunnel" may 1143 provide encryption and data integrity. Both encryption and data 1144 integrity are optional features in TLS. The TLS TMSP MUST provide 1145 authentication if auth is requested in the securityLevel of the SNMP 1146 message request (RFC3412 4.1.1). The TLS TM-security model MUST 1147 specify that the messages be encrypted if priv is requested in the 1148 securityLevel parameter of the SNMP message request (RFC3412 4.1.1). 1150 The TLS TM-security model MUST support the TLS Handshake Protocol 1151 with mutual authentication. 1153 7.1.1. tmStateReference for TLS 1155 Upon establishment of a TLS session, the TMSP will cache the state 1156 information. A unique tmStateReference will be passed to the 1157 corresponding MPSP. The MPSP will pass the securityStateReference to 1158 the Message Processing Model for memory management. 1160 The tmStateReference cache: 1162 tmStateReference 1163 tmSecurityStateReference 1164 tmTransportDomain = TCP/IPv4 1165 tmTransportAddress = x.x.x.x:y 1166 tmSecurityModel - TLS TMSM 1167 tmSecurityName = "dbharrington" 1168 tmSecurityLevel = "authPriv" 1169 tmAuthProtocol = Handshake MD5 1170 tmPrivProtocol = Handshake DES 1171 tmSessionID = Handshake session identifier 1172 tmSessionKey = Handshake peer certificate 1173 tmSessionMasterSecret = master secret 1174 tmSessionParameters = compression method, cipher spec, is- 1175 resumable 1177 7.1.2. MPSP for TLS TM-Security Model 1179 messageProcessingModel = SNMPv3 1180 securityModel = TLS TMSM 1181 securityName = tmSecurityName 1182 securityLevel = msgSecurityLevel 1184 7.1.3. MIB Module for TLS Security 1186 Each security model should use its own MIB module, rather than 1187 utilizing the USM MIB, to eliminate dependencies on a model that 1188 could be replaced some day. See RFC3411 section 4.1.1. 1190 The TLS MIB module needs to provide the mapping from model-specific 1191 identity to a model independent securityName. 1193 [todo] Module needs to be worked out once things become stable... 1195 7.2. DTLS/UDP Transport Mapping Security Model 1197 DTLS has been proposed as a UDP-based TLS. Transport Layer Security 1198 (TLS) [RFC2246] traditionally requires a connection-oriented 1199 transport and is usually used over TCP. Datagram Transport Layer 1200 Security (DTLS) [I-D.rescorla-dtls] provides security services 1201 equivalent to TLS for connection-less transports such as UDP. 1203 DTLS provides all the security services needed from an SNMP 1204 architectural point of view. Although it is possible to derive a 1205 securityName from the public key certificates (e.g. the subject 1206 field), this approach requires installing certificates on all SNMP 1207 entities, leading to a certificate management problem which does not 1208 integrate well with established AAA systems. [todo] why does this not 1209 integrate well with existing AAA systems? 1210 Another option is to run an authentication exchange which is 1211 integrated with TLS, such as Secure Remote Password with TLS 1212 [I-D.ietf-tls-srp]. A similar option would be to use Kerberos 1213 authentication with TLS as defined in [RFC2712]. 1215 It is important to stress that the authentication exchange must be 1216 integrated into the TLS mechanism to prevent man-in-the-middle 1217 attacks. While SASL [RFC2222] is often used on top of a TLS 1218 encrypted channel to authenticate users, this choice seems to be 1219 problematic until the mechanism to cryptographically bind SASL into 1220 the TLS mechanism has been defined. 1222 DTLS will create an association between the TMSM of one SNMP entity 1223 and the TMSM of another SNMP entity. The created "tunnel" may 1224 provide encryption and data integrity. Both encryption and data 1225 integrity are optional features in DTLS. The DTLS TM-security model 1226 MUST provide authentication if auth is requested in the securityLevel 1227 of the SNMP message request (RFC3412 4.1.1). The TLS TM-security 1228 model MUST specify that the messages be encrypted if priv is 1229 requested in the securityLevel parameter of the SNMP message request 1230 (RFC3412 4.1.1). 1232 The DTLS TM-security model MUST support the TLS Handshake Protocol 1233 with mutual authentication. 1235 7.2.1. tmStateReference for DTLS 1237 Upon establishment of a DTLS session, the TMSP will cache the state 1238 information. A unique tmStateReference will be passed to the 1239 corresponding MPSP. The MPSP will pass the securityStateReference to 1240 the Message Processing Model for memory management. 1242 The tmStateReference cache: 1243 tmStateReference 1244 tmSecurityStateReference 1245 tmTransportDomain = UDP/IPv4 1246 tmTransportAddress = x.x.x.x:y 1247 tmSecurityModel - DTLS TMSM 1248 tmSecurityName = "dbharrington" 1249 tmSecurityLevel = "authPriv" 1250 tmAuthProtocol = Handshake MD5 1251 tmPrivProtocol = Handshake DES 1252 tmSessionID = Handshake session identifier 1253 tmSessionKey = Handshake peer certificate 1254 tmSessionMasterSecret = master secret 1255 tmSessionParameters = compression method, cipher spec, is- 1256 resumable 1257 tmSessionSequence = epoch, sequence 1259 [todo] 1260 Need to discuss to what extent DTLS is a reasonable choice for 1261 SNMP interactions. 1262 What is the status of the work to cryptographically bind SASL to 1263 DTLS? 1264 More details need to be worked out... 1266 7.3. SASL Transport Mapping Security Model 1268 The Simple Authentication and Security Layer (SASL) [RFC2222] 1269 provides a hook for authentication and security mechanisms to be used 1270 in application protocols. SASL supports a number of authentication 1271 and security mechanisms, among them Kerberos via the GSSAPI 1272 mechanism. 1274 This sample will use DIGEST-MD5 because it supports authentication, 1275 integrity checking, and confidentiality. 1277 DIGEST-MD5 supports auth, auth with integrity, and auth with 1278 confidentiality. Since SNMPv3 assumes integrity checking is part of 1279 authentication, if msgFlags is set to authNoPriv, the qop-value 1280 should be set to auth-int; if msgFlags is authPriv, then qop-value 1281 should be auth-conf. 1283 Realm is optional, but can be utilized by the securityModel if 1284 desired. SNMP does not use this value, but a TMSM could map the 1285 realm into SNMP processing in various ways. For example, realm and 1286 username could be concatenated to be the securityName value, e.g. 1287 helpdesk::username", or the realm could be used to specify a 1288 groupname to use in the VACM access control. This would be similar 1289 to having the securityName-to-group mapping done by the external AAA 1290 server. 1292 7.3.1. tmStateReference for SASL DIGEST-MD5 1294 The tmStateReference cache: 1295 tmStateReference 1296 tmSecurityStateReference 1297 tmTransportDomain = TCP/IPv4 1298 tmTransportAddress = x.x.x.x:y 1299 tmSecurityModel - SASL TMSM 1300 tmSecurityName = username 1301 tmSecurityLevel = [auth-conf] 1302 tmAuthProtocol = md5-sess 1303 tmPrivProtocol = 3des 1304 tmServicesProvided = 1305 mutual authentication, 1306 reauthentication, 1307 integrity, 1308 encryption 1309 tmParameters = "realm=helpdesk, serv-type=SNMP 1311 8. Security Considerations 1313 This document describes an architectural approach and multiple 1314 proposed configurations that would permit SNMPv3 to utilize transport 1315 layer security services. Each section containing a proposal should 1316 discuss the security considerations of that approach. [todo] expand 1317 as needed. 1319 Perfect forward secrecy guarantees that compromise of long term 1320 secret keys does not result in disclosure of past session keys. 1322 It is considered desirable by some industry segments that SNMP 1323 security models should utilize transport layer security that 1324 addresses perfect forward secrecy at least for encryption keys. 1326 9. Acknowledgments 1328 The Integrated Security for SNMP WG would like to thank the following 1329 people for their contributions to the process: 1331 The authors of submitted security model proposals: Chris Elliot, Wes 1332 Hardaker, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave 1333 Perkins, Joseph Salowey, and Juergen Schoenwaelder. 1335 The members of the Protocol Evaluation Team: Uri Blumenthal, 1336 Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. 1338 WG members who committed to and performed detailed reviews: Jeffrey 1339 Hutzelman, and Nicolas Williams. 1341 10. References 1343 10.1. Normative References 1345 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 1346 Authentication Service (V5)", RFC 1510, September 1993. 1348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1349 Requirement Levels", BCP 14, RFC 2119, March 1997. 1351 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1352 (SASL)", RFC 2222, October 1997. 1354 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1355 RFC 2246, January 1999. 1357 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1358 Schoenwaelder, Ed., "Structure of Management Information 1359 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1361 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1362 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1363 STD 58, RFC 2579, April 1999. 1365 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1366 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1367 April 1999. 1369 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1370 "Remote Authentication Dial In User Service (RADIUS)", 1371 RFC 2865, June 2000. 1373 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1374 Architecture for Describing Simple Network Management 1375 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1376 December 2002. 1378 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1379 "Message Processing and Dispatching for the Simple Network 1380 Management Protocol (SNMP)", STD 62, RFC 3412, 1381 December 2002. 1383 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1384 (USM) for version 3 of the Simple Network Management 1385 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1387 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1388 Management Protocol (SNMP)", STD 62, RFC 3417, 1389 December 2002. 1391 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol 1392 Over Transmission Control Protocol Transport Mapping", 1393 RFC 3430, December 2002. 1395 [I-D.ietf-secsh-architecture] 1396 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 1397 draft-ietf-secsh-architecture-22 (work in progress), 1398 March 2005. 1400 [I-D.ietf-secsh-connect] 1401 Lonvick, C. and T. Ylonen, "SSH Connection Protocol", 1402 draft-ietf-secsh-connect-25 (work in progress), 1403 March 2005. 1405 [I-D.ietf-secsh-transport] 1406 Lonvick, C., "SSH Transport Layer Protocol", 1407 draft-ietf-secsh-transport-24 (work in progress), 1408 March 2005. 1410 [I-D.ietf-secsh-userauth] 1411 Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", 1412 draft-ietf-secsh-userauth-27 (work in progress), 1413 March 2005. 1415 [I-D.rescorla-dtls] 1416 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1417 Security", draft-rescorla-dtls-05 (work in progress), 1418 June 2005. 1420 [I-D.schoenw-snmp-tlsm] 1421 Harrington, D. and J. Schoenwaelder, "Transport Mapping 1422 Security Model (TMSM) for the Simple Network Management 1423 Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-02 1424 (work in progress), May 2005. 1426 10.2. Informative References 1428 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1429 Suites to Transport Layer Security (TLS)", RFC 2712, 1430 October 1999. 1432 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1433 "Introduction and Applicability Statements for Internet- 1434 Standard Management Framework", RFC 3410, December 2002. 1436 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1437 Management Protocol (SNMP) Applications", STD 62, 1438 RFC 3413, December 2002. 1440 [I-D.ietf-netconf-prot] 1441 Enns, R., "NETCONF Configuration Protocol", 1442 draft-ietf-netconf-prot-09 (work in progress), 1443 October 2005. 1445 [I-D.ietf-netconf-ssh] 1446 Wasserman, M. and T. Goddard, "Using the NETCONF 1447 Configuration Protocol over Secure Shell (SSH)", 1448 draft-ietf-netconf-ssh-04 (work in progress), April 2005. 1450 [I-D.ietf-secsh-gsskeyex] 1451 Hutzelman, J., "GSSAPI Authentication and Key Exchange for 1452 the Secure Shell Protocol", draft-ietf-secsh-gsskeyex-10 1453 (work in progress), August 2005. 1455 [I-D.ietf-tls-srp] 1456 Taylor, D., "Using SRP for TLS Authentication", 1457 draft-ietf-tls-srp-10 (work in progress), October 2005. 1459 Appendix A. Questions about msgFlags: 1461 [todo] many of these questions can be resolved by deciding whether 1462 the TMSP or MPSP provides the service of comparing msgFlags (from 1463 inside the message) to actual capabilities of the transport layer 1464 security (external to the message). It may however be necessary to 1465 provide this service for two slightly different purposes depending on 1466 whether the message is outgoing (and may need to be checked by the 1467 TMSP when a new transport session might be created) or the message is 1468 incoming ( the capabilities of the transport layer session are 1469 already known, but msgFlags has not been unpacked yet at the TMSP, so 1470 the comparison must be done at the MPSP). Of course, we really only 1471 need to compare the authflag and the privflag, i.e. the 1472 securityLevel, so if we pass the securityLevel between the two 1473 stages, then they each have the info they need to do their respective 1474 comparisons. 1476 There have been a large number of questions about msgFlags in the 1477 TMSM approach, mostly concerning the msgFlags value and the actual 1478 security provided, and whether msgFlags can be used to initiate per- 1479 message or per-session security. 1481 A.1. msgFlags versus actual security 1483 Using IPSEC, SSH, or SSL/TLS to provide security services "below" the 1484 SNMP message, the use of securityName and securityLevel will differ 1485 from the USM/VACM approach to SNMP access control. VACM uses the 1486 "securityName" and the "securityLevel" to determine if access is 1487 allowed. With the SNMPv3 message and USM security model, both 1488 securityLevel and securityName are contained in every SNMPv3 message. 1490 Any proposal for a security model using IPSEC, SSH, or SSL/TLS needs 1491 to specify how this info is made available to the SNMPv3 message 1492 processing, and how it is used. 1494 One specific case to consider is the relationship between the 1495 msgFlags of an SNMPv3 message, and the actual services provided by 1496 the lower layer security. For example, if a session is set up with 1497 encryption, is the priv bit always (or never) set in the msgFlags 1498 field, and is the PDU never (or always) encrypted? Do msgFlags have 1499 to match the security services provided by the lower layer, or are 1500 the msgFlags ignored and the values from the lower layer used? 1502 Is the securityLevel looked at before the security model gets to 1503 it.? No. the security model has two parts - the TMSP and the 1504 MPSP. The securityLevel is looked at by the TMSP before it gets 1505 to the MPSP, but both are parts of the same security model. 1506 Would it be legal for the security model to ignore the incoming 1507 flags and change them before passing them back up? If it changed 1508 them, it wouldn't necessarily be ignoring them. The TMSP should 1509 pass both an actual securityLevel applied to the message, and the 1510 msgFlags in the SNMP message to the MPSP for consideration related 1511 to access control.. The msgFlags parameter in the SNMP message is 1512 never changed when processing an incoming message. 1513 Would it be legal for the security model to ignore the outgoing 1514 flags and change them before passing them out? no; because the two 1515 stages are parts of the same security model, either the MPSP 1516 should recognize that a securityLevel cannot be met or exceeded, 1517 and reject the message during the message-build phase, or the TMSP 1518 should determine if it is possible to honor the request. It is 1519 possible to apply an increased securityLevel for an outgoing 1520 request, but the procedure to do so must be spelled out clearly in 1521 the model design. 1522 The security model MUST check the incoming security level flags to 1523 make sure they matched the transport session setup. and if not 1524 drop the message. Yes, mostly. Depending on the model, either 1525 the TMSP or the MPSP MUST verify that the actual processing met or 1526 exceeded the securityLevel requested by the msgFlags and that it 1527 is acceptable to the specific-model processing (or operator 1528 configuration) for this different securityLevel to be applied to 1529 the message. This is also true (especially) for outgoing 1530 messages. 1531 You might legally be able to have a authNoPriv message that is 1532 actually encrypted via the transport (but not the other way around 1533 of course). Yes, a TMSM could define that as the behavior (or 1534 permit an operator to specify that is acceptable behavior) when a 1535 requested securityLevel cannot be provided, but a stronger 1536 securityLevel can be provided. 1538 A.2. Message security versus session security 1540 For SBSM, and for many TMSM models, securityName is specified 1541 during session setup, and associated with the session identifier. 1542 Is it possible for the request (and notification) originator to 1543 specify per message auth and encryption services, or are they 1544 "fixed" by the transport/session model? 1545 If a session is created as 'authPriv', then keys for encryption 1546 would still be negotiated once at the beginning of the session. 1547 But if a message is presented to the session with a security level 1548 of authNoPriv, then that message could simply be authenticated and 1549 not encrypted. Wouldn't that also have some security benefit, in 1550 that it reduces the encrypted data available to an attacker 1551 gathering packets to try and discover the encryption keys? 1552 Some SNMP entities are resource-constrained. Adding sessions 1553 increases the need for resources, we shouldn't require two 1554 sessions when one can suffice. 2 bytes per session structure and a 1555 compare or two is much less of a resource burden than two separate 1556 sessions. 1557 It's not just about CPU power of the device but the percentage of 1558 CPU cycles that are spent on network management. There isn't much 1559 value in using encryption for a performance management system 1560 polling PEs for performance data on thousands of interfaces every 1561 ten minutes, it just adds significant overhead to processing of 1562 the packet. Using an encrypted TLS channel for everything may not 1563 work for use cases in performance management wherein we collect 1564 massive amounts of non sensitive data at periodic intervals. Each 1565 SNMP "session" would have to negotiate two separate protection 1566 channels (authPriv and authNoPriv) and for every packet the SNMP 1567 engine will use the appropriate channel based on the desired 1568 securityLevel. 1569 If the underlying transport layer security was configurable on a 1570 per-message basis, a TMSM could have a MIB module with 1571 configurable maxSecurityLevel and a minSecurityLevel objects to 1572 identify the range of possible levels, and not all messages sent 1573 via that session are of the same level. A session's 1574 maxSecurityLevel would identify the maximum security it could 1575 provide, and a session created with a minSecurityLevel of authPriv 1576 would reject an attempt to send an authNoPriv message. 1578 Authors' Addresses 1580 David Harrington 1581 Effective Software 1582 Harding Rd 1583 Portsmouth NH 1584 USA 1586 Phone: +1 603 436 8634 1587 Email: dbharrington@comcast.net 1589 Juergen Schoenwaelder 1590 International University Bremen 1591 Campus Ring 1 1592 28725 Bremen 1593 Germany 1595 Phone: +49 421 200-3587 1596 Email: j.schoenwaelder@iu-bremen.de 1598 Full Copyright Statement 1600 Copyright (C) The Internet Society (2005). 1602 This document is subject to the rights, licenses and restrictions 1603 contained in BCP 78, and except as set forth therein, the authors 1604 retain all their rights. 1606 This document and the information contained herein are provided on an 1607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1609 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1610 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1611 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1614 Intellectual Property 1616 The IETF takes no position regarding the validity or scope of any 1617 Intellectual Property Rights or other rights that might be claimed to 1618 pertain to the implementation or use of the technology described in 1619 this document or the extent to which any license under such rights 1620 might or might not be available; nor does it represent that it has 1621 made any independent effort to identify any such rights. Information 1622 on the procedures with respect to rights in RFC documents can be 1623 found in BCP 78 and BCP 79. 1625 Copies of IPR disclosures made to the IETF Secretariat and any 1626 assurances of licenses to be made available, or the result of an 1627 attempt made to obtain a general license or permission for the use of 1628 such proprietary rights by implementers or users of this 1629 specification can be obtained from the IETF on-line IPR repository at 1630 http://www.ietf.org/ipr. 1632 The IETF invites any interested party to bring to its attention any 1633 copyrights, patents or patent applications, or other proprietary 1634 rights that may cover technology that may be required to implement 1635 this standard. Please address the information to the IETF at 1636 ietf-ipr@ietf.org. 1638 Acknowledgment 1640 Funding for the RFC Editor function is currently provided by the 1641 Internet Society.