idnits 2.17.1 draft-ietf-snmpv3-next-gen-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 40) being 79 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 81 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 756: '... bytes long, and MUST always be at lea...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (17 June 1997) is 9807 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: 'RFC1155' is defined on line 1456, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 1466, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 1478, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 1487, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 1497, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1507, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 1512, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1445 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (ref. 'RFC1902') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) -- Duplicate reference: RFC1905, mentioned in 'RFC1905', was also mentioned in 'RFC1902'. ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) ** Downref: Normative reference to an Historic RFC: RFC 1909 ** Downref: Normative reference to an Historic RFC: RFC 1910 Summary: 24 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 An Architecture for Describing 3 Internet Management Frameworks 5 17 June 1997 7 D. Harrington 8 Cabletron Systems, Inc. 9 dbh@cabletron.com 11 B. Wijnen 12 IBM T.J. Watson Research 13 wijnen@vnet.ibm.com 15 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-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 material 27 or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 Abstract 36 This document describes an architecture for describing Internet 37 Management Frameworks. The architecture is designed to be modular 38 to allow the evolution of the protocol over time. The major portions 39 of the architecture are a messaging engine containing a message 40 processing and control subsystem and a security subsystem, plus a 41 data processing engine, called a context engine, which contains an 42 access control subsystem, a MIB access subsystem, and possibly 43 multiple orangelets which provide specific functional processing 44 of network management data. 46 Harrington/Wijnen Expires December 1977 [Page 1] 47 Harrington/Wijnen Expires December 1977 [Page 2] 48 0. Issues 50 0.1. Issues to be resolved 51 . Need the "readable" introduction supplement 52 . taxonomy: 53 orangelets 54 . should the scopedPDU be contained in the securityParameters 55 SEQUENCE, so encryption can include the PDU and some of the 56 security parameters? 57 . Who counts SNMP messages? who counts snmpv3 messages? 58 . reportPDUs created from an error status or OID returned by the appropriate 59 subsystem/model? 60 . foward refreences need to be handled 61 . some TCs were defined for interface parameters, but aren't part of a mIB. 62 move to Glossary? 63 . Is AdminString appropriate for all strings, such as securityidentifier and 64 context and group? These had different sizes and semantics. 65 . AdminString has size (1..255); what about default context of ""? 66 . snmpEngineMaxMessageSize maximum size? 65507? what about non-UDP transports? 67 . description of max message size 68 . definitioon/description of MD5/DES protocol OIDs. 69 . should the tree for registering protocols be in basicGroup? 70 . should User-based be in basicgroup conformance? 71 . how does MPC match incoming requests with outgoing responses? 72 . generateRequestMessage( globalData, scopedPDU, MIID, engineID ) 73 why do we need engineID? isn't that implicit? 74 . I rearranged primitive parameters: transport/engine/contextEngine/PDU 75 . state_refernce releases - are these consistently defined? 76 . should the MPC release the state_reference when it receives a response? 77 . How is duplicate registration handled? error or ignore? 79 0.2. Change Log 81 [version 3.1] 82 . change securityIdentity to MIID 83 . write text to explain the differences between security-identities, 84 model-dependent identifiers, and model-independent identifiers. 85 . write text to explain distinction within the LCD of the security 86 data, the access control data, and the oranglet data. 87 . identify issues 88 . publish as 90 [version 3.0] 91 . add section on threats for message security 92 . add section on threats for access control 93 . change application to orangelet 94 . remove references to F-Ts 95 . change securityIdentity to security-identity 96 . change securityCookie to securityIdentity 97 . the format of securityIdentity is defined by the model 98 . add securityModel to passed parameters as needed 100 Harrington/Wijnen Expires December 1977 [Page 3] 101 . eliminate group from passed parameters 102 . remove unused IMPORTS 103 . add glossary section with initial set of words to define 104 . differentiate the messageEngine from the contextEngine 105 . eliminate the term SNMPng 106 . rewrote 1.1. A Note on Terminology 107 . eliminated assumptions about SNMP processing always being 108 message related 109 . rewrote 4.x to reflect new thinking 110 . rewrote 5.x to reflect new thinking 111 . rewrote 6.x (the MIB) to reflect new thinking 112 . added MIB objects at this level (previously only T-Cs) 113 . rewrote 7.x 114 . sent to v3edit list 116 Harrington/Wijnen Expires December 1977 [Page 4] 117 1. Introduction 119 A management system contains: several (potentially many) nodes, each 120 with a processing entity, termed an agent, which has access to 121 management instrumentation; at least one management station; and, a 122 management protocol, used to convey management information between the 123 agents and management stations, or between management stations and 124 other management stations. 126 Management stations execute management applications which monitor and 127 control managed elements. Managed elements are devices such as hosts, 128 routers, terminal servers, etc., which are monitored and controlled via 129 access to their management information. 131 Operations of the protocol are carried out under an administrative 132 framework which defines minimum requirements for standard services, 133 such as sending and receiving messages, countering security threats to 134 messages, controlling access to managed objects, and processing various 135 types of requests. 137 It is the purpose of this document to define an architecture which 138 can evolve to realize effective network management in a variety 139 of configurations and environments. The architecture has been 140 designed to meet the needs of implementors of minimal agents, command 141 line driven managers, mid-level managers, and full-function network 142 enterprise management stations. 144 1.1. A Note on Terminology 146 This architecture is designed to allow an orderly evolution of 147 portions of SNMP Frameworks. 149 Throughout the rest of this document, the term "subsystem" will 150 refer to an abstract and incomplete specification of a portion of 151 a Framework, that will be further refined by a model specification. 153 A "model" describes a specific design of a subsystem, defining 154 additional constraints and rules for conformance to the model. 155 A model is sufficiently detailed to make it possible to implement 156 the specification. 158 A "implementation" is an instantiation of a subsystem, conforming to a 159 specific model. 161 SNMP version 1 (SNMPv1), is the original Internet-standard Network 162 Management Framework, as described in RFCs 1155, 1157, and 1212. 164 SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1, 165 as described in RFCs 1902-1908. SNMPv2 has an incomplete message 166 definition. 168 Harrington/Wijnen Expires December 1977 [Page 5] 169 Community-based SNMP version 2 (SNMPv2c) is an experimental Framework 170 which supplements the incomplete message format of SNMPv2 with 171 portions of the message format of SNMPv1, as described in RFC1901. 173 SNMP version 3 (SNMPv3) Framework is a particular configuration of 174 implemented subsystems, consistent with the architecture described 175 in this document. 177 Other SNMP Frameworks, i.e. other configurations of implemented 178 subsystems, are expected to also be consistent with this architecture. 180 This document does not describe any framework, but describes an 181 architecture into which multiple frameworks may be fitted. 183 2. Overview 185 The architecture presented here emphasizes the use of modularity to 186 allow the evolution of portions of SNMP without requiring a redesign 187 of the general architecture of SNMP. 189 SNMP processing must be performed in consistently ordered steps, which 190 fall into general categories of similar functionality. This document 191 will describe major abstractions of functionality required during 192 SNMP processing, and the abstract interactions between these major 193 categories of functionality. 195 This document will describe how this architecture is meant to allow 196 modules of functionality corresponding to these abstract categories to 197 be designed to allow the evolution of the whole by modifying discrete 198 modules within the architecture. 200 Harrington/Wijnen Expires December 1977 [Page 6] 201 3. An Evolutionary Architecture - Design Goals 203 The goals of the architectural design are to use encapsulation, 204 cohesion, hierarchical rules, and loose coupling to reduce complexity 205 of design and make the evolution of portions of the architecture 206 possible. 208 3.1. Encapsulation 210 Encapsulation describes the practice of hiding the details that are 211 used internal to a process. Some data is required for a given 212 procedure, but isn't needed by any other part of the process. 214 In networking, the concept of a layered stack reflects this approach. 215 The transport layer contains data specific to its processing; the data 216 is not visible to the other layers. In programming this is reflected 217 in language elements such as "file static" variables in C, and 218 "private" in C++, etc. 220 In this architecture, all data used for processing only within 221 a functional portion of the architecture should have its visibility 222 restricted to that portion if possible. The data should be accessed 223 only by that functionality defined with the data. No reference to the 224 data should be made from outside the functional portion of the 225 architecture, except through predefined public interfaces. 227 3.2. Cohesion 229 Similar functions can be grouped together and their differences 230 ignored, so they can be dealt with as a single entity. It is important 231 that the functions which are grouped together are actually similar. 232 Similarity of the data used to perform functions can be a good 233 indicator of the similarity of the functions. 235 For example, authentication and encryption are both security functions 236 which are applied to a message. Access control, while similar in some 237 ways, is dissimilar in that it is not applied to a message, it is 238 applied to a (proposed) request for a management operation. 239 The data required to perform authentication and encryption are 240 different than the data needed to perform access control, and the 241 two sets of services can be described independently. 243 Similar functions, especially those that use the same data elements, 244 should be defined together. The security functions which operate at 245 the message level should be defined in a document together with the 246 definitions for those data elements that are used only by those 247 security functions. For example, a MIB with authentication keys is 248 used only by authentication functions; they should be defined together. 250 Harrington/Wijnen Expires December 1977 [Page 7] 251 3.3. Hierarchical Rules 253 Functionality can be grouped into hierarchies where each element in the 254 hierarchy receives general characteristics from its direct superior, 255 and passes on those characteristics to each of its direct subordinates. 257 This architecture uses the hierarchical approach by defining 258 subsystems, which specify the general rules of a portion of the system, 259 models which define the specific rules to be followed by an 260 implementation of the portion of the system, and implementations which 261 encode those rules into reality for a portion of the system. 263 It is expected that within portions of the system, hierarchical 264 relationships will be used to compartmentalize, or modularize, the 265 implementation of specific functionality. For example, it is expected 266 that within the security portion of the system, authentication and 267 privacy will probably be contained in separate modules, and that 268 multiple authentication and privacy mechanisms will be supported by 269 allowing supplemental modules that provide protocol-specific 270 authentication and privacy services. 272 3.4. Coupling 274 Coupling describes the amount of interdependence between parts of 275 a system. Loose coupling indicates that two sub-systems are relatively 276 independent of each other; tight coupling indicates a high degree of 277 mutual dependence. 279 To make it possible to evolve the architecture by replacing only part 280 of the system, or by supplementing existing portions with alternate 281 mechanisms for similar functionality, without obsoleting the complete 282 system, it is necessary to limit the coupling of the parts. 284 Encapsulation and cohesion help to reduce coupling by limiting the 285 visibility of those parts that are only needed within portions of a 286 system. Another mechanism is to constrain the nature of interactions 287 between various parts of the system. 289 This can be done by defining fixed, generic, flexible interfaces 290 for transferring data between the parts of the system. The concept of 291 plug-and-play hardware components is based on that type of interface 292 between the hardware component and system into which it will be 293 "plugged." 295 This approach has been chosen so individual portions of the system 296 can be upgraded over time, while keeping the overall system intact. 298 To avoid specifying fixed interfaces, which would constrain a vendor's 299 choice of implementation strategies, a set of abstract data elements 300 is used for (conceptually) transferring data between subsystems in 301 documents which describe subsystem or model interactions. Documents 303 Harrington/Wijnen Expires December 1977 [Page 8] 304 describing the interaction of subsystems or models should use only 305 the abstract data elements provided for transferring data but vendors 306 are not constrained to using the described data elements for 307 transferring data between portions of their implementation. 309 Loose coupling works well with the IETF standards process. If we 310 separate message-handling from security and from local processing, 311 then the separate portions of the system can move through the standards 312 process with less dependence on the status of the other portions of the 313 standard. Security models may be able to be re-opened for discussion 314 due to patents, new research, export laws, etc., as is clearly expected 315 by the WG, without needing to reopen the documents which detail the 316 message format or the local processing of PDUs. Thus, the standards 317 track status of related, but independent, documents is not affected. 319 Harrington/Wijnen Expires December 1977 [Page 9] 320 4. Abstract Functionality 322 DBH: {ref: Get-Request, PDU, authentication, encryption, timeliness, 323 managed objects, proxy, } 325 The architecture described here contains four subsystems, each 326 capable of being defined as one or more different models which may 327 be replaced or supplemented as the growing needs of network management 328 require. The subsystems are a Message Processing and Control 329 subsystem, a Security subsystem, an Orangelet subsystem, and an 330 Access Control subsystem. 332 The subsystems are contained in two "engines". 334 A messageEngine deals with SNMP messages, and is responsible for 335 sending and receiving messages, including having authentication 336 and encryption services applied to the messages, and determining 337 to which Orangelet the message contents should be delivered. 339 A contextEngine deals with processing network management operations, 340 and contains subsystems for Access Control, MIB access, and 341 Orangelets which provide specific functional processing. 342 Depending on the network management service needed, an Orangelet 343 may use the access control and MIB access subsystems, and may use 344 SNMP messages to communicate with remote nodes. The network 345 management service may be requested via the payload of an SNMP 346 message, or may be requested via a local process. 348 4.1. The messageEngine 350 The messageEngine interacts with the network using SNMP messages, 351 and with the message processing subsystem and the security subsystem 352 and with orangelets using service interfaces defined within this 353 architecture. 355 4.1.1. Transport Mappings 357 SNMP messages are sent to, or received from, the network using 358 transport addresses. It is the responsibility of the messageEngine 359 to listen at the appropriate local addresses, and to send messages 360 through the appropriate addresses, consistent with mappings defined 361 by SNMP Transport Mapping documents, such as RFC1906. 363 4.1.2. SNMP-Based Message Formats 365 SNMP messages sent to, or received from, the network use a format 366 defined by a version-specific Message Processing and Control model. 367 The messageEngine determines to which version-specific model the 368 message should be given. 370 The version-specific model interacts with the security subsystem, 371 using a service interface defined by this architecture, to procure 372 security services to meet the requirements of the version-specific 373 protocol. 375 4.1.3. The Interface to Orangelets 377 A messageEngine, as a result of the receipt of an SNMP message, may 378 initiate a transaction with an Orangelet, such as for an incoming 379 request, or an Orangelet may initiate a transaction with a 380 messageEngine, such as for an outgoing request. The messageEngine 381 determines to which orangelet a message should be given. 383 4.1.4. Protocol Instrumentation 385 To monitor and manage an SNMP engine, a Management Information Base 386 for SNMP defines the collection of managed objects which instrument 387 the SNMP protocol itself. The messageEngine has the responsibility 388 for maintaining the instrumentation that is described by the 389 SNMPv2 MIB module [RFC1907] plus the instrumentation which is 390 described by the IMFMIB module defined in this document. 392 A Message Processing and Control model may require support for 393 MIB modules related to instrumenting version-specific aspects 394 of the SNMP protocol. 396 4.2. Security 398 Some environments require secure protocol interactions. Security is 399 normally applied at two different stages - in the transmission/receipt 400 of messages, and in the processing of the contents of messages. For 401 purposes of this document, "security" refers to message-level security; 402 "access control" refers to the security applied to protocol operations. 404 Authentication, encryption, and timeliness checking are common 405 functions of message level security. 407 4.3. Orangelets 409 Orangelets coordinate the processing of management information 410 operations. 412 This document describes three common types of orangelets 413 and how they interact within the architecture - 1) an orangelet 414 may process requests to perform an operation on managed objects, 415 2) an orangelet may initiate a transaction as the result of a 416 local event, and 3) an orangelet may act as an intermediary, 417 forwarding an operation to another network management entity. 419 Orangelets provide access to MIB information, and coordinate 420 the application of access control to management operations. 422 A discussion of the management information and processing is 423 provided here, but an Orangelet model defines which set of 424 documents are used to specifically define the structure of management 425 information, textual conventions, conformance requirements, and 426 operations supported by the Orangelet. 428 4.4.1. Structure of Management Information 430 Management information is viewed as a collection of managed objects, 431 residing in a virtual information store, termed the Management 432 Information Base (MIB). Collections of related objects are defined 433 in MIB modules. 435 It is the purpose of a Structure of Management Information 436 document to establish the syntax for defining objects, modules, and 437 other elements of managed information. 439 An Orangelet model defines which SMI documents are supported 440 by the model. 442 4.4.2. Textual Conventions 444 When designing a MIB module, it is often useful to define new types 445 similar to those defined in the SMI, but with more precise semantics, 446 or which have special semantics associated with them. These newly 447 defined types are termed textual conventions. 449 An Orangelet model defines which Textual Conventions documents 450 are supported by the model. 452 4.4.3. Conformance Statements 454 It may be useful to define the acceptable lower-bounds of 455 implementation, along with the actual level of implementation 456 achieved. It is the purpose of Conformance Statements to define 457 the notation used for these purposes. 459 An Orangelet model defines which Conformance Statement documents 460 are supported by the model. 462 4.4.4. Protocol Operations 464 SNMP messages encapsulate a Protocol Data Unit (PDU). It is the 465 purpose of a Protocol Operations document to define the operations 466 of the protocol with respect to the processing of the PDUs. 468 An Orangelet model defines which Protocol Operations documents 469 are supported by the model. 471 4.5. Access Control 473 During processing, it may be required to control access to certain 474 instrumentation for certain operations. The determination of 475 access rights requires the means to identify the access allowed for 476 the security-identity on whose behalf a request is generated. 478 An Access Control model provides an advisory service for an 479 Orangelet. The determination of whether to check access control 480 policy is the responsibility of the Orangelet model. The mechanism 481 by which access control is checked is defined by the Access Control 482 model. 484 4.6. Coexistence 486 The purpose of an evolutionary architecture is to permit new models 487 to replace or supplement existing models. The interactions between 488 models could result in incompatibilities, security "holes", and 489 other undesirable effects. 491 The purpose of a Coexistence document is to detail recognized anomalies 492 and to describe required and recommended behaviors for resolving the 493 interactions between models within the architecture. 495 It would be very difficult to document all the possible interactions 496 between a model and all other previously existing models while in the 497 process of developing a new model. 499 Coexistence documents are therefore expected to be prepared separately 500 from model definition documents, to describe and resolve interaction 501 anomalies between a model definition and one or more other model 502 definitions. 504 5. Abstract Data Elements of the Architecture 506 This section contains definitions of abstract data elements used to 507 transfer data between subsystems. 509 5.1. engineID 511 Each SNMP engine, consisting of potentially many subsystems, must be 512 able to be uniquely identified. The mechanism by which this can be 513 done is defined in the IMFMIB module, described in this document, 514 since it is desirable that engine identification span all frameworks. 516 5.2. SecurityIdentity 518 A generic term for an uniquely-identifiable entity on whose behalf 519 a message can be generated. Each security subsystem may define a 520 model-specific mechanism for entity identification, such as a 521 community [RFC1157] or user [RFC1910] or party-pair [RFC1445]. 522 This model-specific identifier is not guaranteed to be represented 523 in a character set readable by humans. 525 5.3. Model Independent Identifier (MIID) 527 Each security model must also provide a mapping from the model 528 specific identification to an SnmpAdminString representation, 529 called the MIID, which, in combination with the securityModel, 530 can be used by all other subsystems within an engine to identify 531 a security identity, regardless of the security mechanisms used to 532 provide security services. 534 The combination of engineID and securityModel and MIID provides a 535 globally-unique identifier for an entity on whose behalf a message 536 can be generated. 538 5.4. Level of Security 540 Messages may require different levels of security. The acronym LoS is 541 used to refer to the level of security. 543 This architecture recognizes three levels of security: 544 - without authentication and without privacy (noAuth/noPriv) 545 - with authentication but without privacy (auth/noPriv) 546 - with authentication and with privacy (auth/Priv) 548 Every message has an associated LoS; all subsystems (security, access 549 control, orangelets, message processing and control) are required 550 to abide the specified LoS while processing the message and its 551 contents. 553 5.5. Contexts 555 An SNMP context is a collection of management information 556 accessible by an SNMP engine. An item of management information 557 may exist in more than one context. An SNMP engine potentially 558 has access to many contexts. 560 5.6. ContextName 562 An octet string used to name a context. Each context must be uniquely 563 named within an engine. 565 5.7. ContextEngineID 567 A contextEngineID uniquely identifies an engine that may realize 568 an instance of a named context. 570 5.8. Naming Scope 572 The combination of a contextEngineID and a contextName uniquely 573 identifies a context within an administrative domain, and is called 574 a naming scope. 576 5.9. Scoped-PDU 578 A scopedPDU contains a Naming-Scope and a PDU. 580 The Naming Scope unambiguously identifies, within the administrative 581 domain, the context to which the SNMP management information in 582 the PDU refers. 584 The PDU format is defined by an Orangelet model, or a document 585 referenced by an Orangelet model, which processes the PDU contents. 587 5.10. PDU-MMS 589 the maximum size of a scopedPDU to be included in a response message, 590 given the amount of reserved space in the message for the anticipated 591 security parameters. 593 5.11. Local Configuration Datastore 595 The subsystems and models in an SNMP engine may need to retain their 596 own, possibly multiple, sets of information to perform their 597 processing. To allow these sets of information to be remotely 598 configured, portions may need to be accessible as managed objects. 600 The collection of these possibly multiple sets of information is 601 referred to collectively as an engine's Local Configuration Datastore 602 (LCD). 604 5.11.1. Security Portion of the Local Configuration Datastore 606 Each Security model may need to retain its own set of information about 607 security entities, mechanisms, and policies. 609 5.11.2. Orangelet Portion of the Local Configuration Datastore 611 Each Orangelet model may need to retain its own set of information 612 about contexts, naming scopes, and other configuration data. 614 5.11.3. Access Control Portion of the Local Configuration Datastore 616 Each Access Control model may need to retain its own set of 617 information about access control policies, and the MIIDs 618 to which the policies apply. 620 5.12. Groups 622 A Group identifies a set of zero or more MIIDs on whose 623 behalf SNMP managed objects are being processed, subject to access 624 control policies common to all members of the group. 626 6. Definition of Managed Objects for Internet Management Frameworks 628 IMF-MIB DEFINITIONS ::= BEGIN 630 IMPORTS 631 MODULE-IDENTITY, OBJECT-TYPE, snmpModules, 632 Unsigned32, Integer32 FROM SNMPv2-SMI 633 TEXTUAL-CONVENTION FROM SNMPv2-TC 634 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 636 imfMIB MODULE-IDENTITY 637 LAST-UPDATED "9706160000Z" -- 16 June 1997, midnight 638 ORGANIZATION "SNMPv3 Working Group" 639 CONTACT-INFO "WG-email: snmpv3@tis.com 640 Subscribe: majordomo@tis.com 641 In message body: subscribe snmpv3 643 Chair: Russ Mundy 644 Trusted Information Systems 645 postal: 3060 Washington Rd 646 Glenwood MD 21738 647 email: mundy@tis.com 648 phone: 301-854-6889 650 Co-editor Dave Harrington 651 Cabletron Systems, Inc 652 postal: Post Office Box 5005 653 MailStop: Durham 654 35 Industrial Way 655 Rochester NH 03867-5005 656 email: dbh@cabletron.com 657 phone: 603-337-7357 659 Co-editor: Bert Wijnen 660 IBM T.J. Watson Research 661 postal: Schagen 33 662 3461 GL Linschoten 663 Netherlands 664 email: wijnen@vnet.ibm.com 665 phone: +31-348-412-498 667 " 668 DESCRIPTION "The Internet Management Architecture MIB" 669 ::= { snmpModules 99 } 671 -- Textual Conventions used in the Internet Management Architecture *** 673 SnmpEngineID ::= TEXTUAL-CONVENTION 674 STATUS current 675 DESCRIPTION "An SNMP engine's administratively-unique identifier. 677 The value for this object may not be all zeros or 678 all 'ff'H. 680 The initial value for this object may be configured 681 via an operator console entry or via an algorithmic 682 function. In the later case, the following 683 guidelines are recommended: 685 1) The first four octets are set to the binary 686 equivalent of the agent's SNMP network management 687 private enterprise number as assigned by the 688 Internet Assigned Numbers Authority (IANA). 689 For example, if Acme Networks has been assigned 690 { enterprises 696 }, the first four octets would 691 be assigned '000002b8'H. 693 2) The remaining eight octets are the cookie whose 694 contents are determined via one or more 695 enterprise specific methods. Such methods must 696 be designed so as to maximize the possibility 697 that the value of this object will be unique in 698 the agent's administrative domain. For example, 699 the cookie may be the IP address of the agent, 700 or the MAC address of one of the interfaces, 701 with each address suitably padded with random 702 octets. If multiple methods are defined, then 703 it is recommended that the cookie be further 704 divided into one octet that indicates the 705 method being used and seven octets which are 706 a function of the method. 707 " 708 SYNTAX OCTET STRING (SIZE (12)) 710 SnmpSecurityModel ::= TEXTUAL-CONVENTION 711 STATUS current 712 DESCRIPTION "An identifier that uniquely identifies a model of 713 security subsystem within the Internet 714 Management Architecture. 715 " 716 SYNTAX INTEGER(0..2147483647) 718 -- BW to DBH: why do we need the following TC? It is never used in a MIB 719 -- is it? 720 -- DBH to BW: I defined this only because it was used in an architectural 721 -- interface, and felt that the architecture should define the 722 -- limits of the syntax, and provide a common description. 723 -- 724 -- SnmpSecurityStateReference ::= TEXTUAL-CONVENTION 725 -- STATUS current 726 -- DESCRIPTION "An implementation-defined reference to the retained 727 -- security information required to send a response. 729 -- The security model defines what information must be 730 -- retained for use in sending the response. 731 -- " 732 -- SYNTAX OCTET STRING 734 SnmpLoS ::= TEXTUAL-CONVENTION 735 STATUS current 736 DESCRIPTION "A level of security at which SNMP messages can be 737 sent; in particular, one of: 738 noAuth - without authentication and without privacy, 739 auth - with authentication but without privacy, 740 priv - with authentication and with privacy. 741 " 742 SYNTAX INTEGER { noAuth(1), auth(2), priv(3) } 744 SnmpAdminString ::= TEXTUAL-CONVENTION 745 STATUS current 746 DESCRIPTION "An octet string containing an SNMP administrative 747 string. Preferably this a a human readable string. 748 We're still thinking if this could use the UTF8 749 character set. 750 " 751 SYNTAX OCTET STRING (SIZE(1..255)) 753 -- BW to DBH: I think these are no longer needed. They now use the 754 -- SnmpV3AdminString TC. 755 -- DBH to BW: so now all securityidentities, Gropups, and Contxets 756 -- can be up to 255 bytes long, and MUST always be at least 757 -- one byte in length? What is our new default context? 758 -- 759 -- SnmpSecurityIdentity ::= TEXTUAL-CONVENTION 760 -- STATUS current 761 -- DESCRIPTION "A octet string which contains data in a format 762 -- defined by a security model which identifies a 763 -- unique identity for which messages may be generated. 764 -- The securityIdentity must be unique across all 765 -- securityModels supported by the engine. 766 -- " 767 -- SYNTAX DisplayString (SIZE (0..32)) 768 -- 769 -- SnmpGroupName ::= TEXTUAL-CONVENTION 770 -- STATUS current 771 -- DESCRIPTION "An octet string which identifies a set of zero or 772 -- more security entities on whose behalf SNMP managed 773 -- objects are being processed, subject to access 774 -- control policies common to all members of the group. 775 -- " 776 -- SYNTAX OCTET STRING (SIZE(1..16)) 777 -- 778 --SnmpContextName ::= TEXTUAL-CONVENTION 779 -- STATUS current 780 -- DESCRIPTION "A name which uniquely identifies a set of 781 -- management information realized by an SNMP engine. 782 -- " 783 -- SYNTAX OCTET STRING (SIZE (0..32)) 784 -- 785 -- 786 -- The IMF Engine Group 787 -- 789 -- Administrative assignments **************************************** 791 imfAdmin OBJECT IDENTIFIER ::= { imfMIB 1 } 792 imfMIBObjects OBJECT IDENTIFIER ::= { imfMIB 2 } 793 imfMIBConformance OBJECT IDENTIFIER ::= { imfMIB 3 } 795 -- the imfEngine group *********************************************** 797 imfEngine OBJECT IDENTIFIER ::= { imfMIBObjects 1 } 799 snmpEngineID OBJECT-TYPE 800 SYNTAX SnmpEngineID 801 MAX-ACCESS read-only 802 STATUS current 803 DESCRIPTION "An SNMP engine's administratively-unique identifier. 804 " 805 ::= { imfEngine 1 } 807 snmpEngineBoots OBJECT-TYPE 808 SYNTAX Unsigned32 -- (1..4294967295) 809 MAX-ACCESS read-only 810 STATUS current 811 DESCRIPTION "The number of times that the engine has re-initialized 812 itself since its initial configuration. 813 " 814 ::= { imfEngine 2 } 816 snmpEngineTime OBJECT-TYPE 817 SYNTAX Integer32 (0..2147483647) 818 MAX-ACCESS read-only 819 STATUS current 820 DESCRIPTION "The number of seconds since the engine last 821 incremented the snmpEngineBoots object. 822 " 823 ::= { imfEngine 3 } 825 snmpEngineMaxMessageSize OBJECT-TYPE 826 -- SYNTAX Integer32 (484..2147483647) 827 -- From BW to DBH: why did you use that large range? The 65507 is the 828 -- max that fits in a UDP datagram. I thought we 829 -- reached consensus on that on the mailinglist. 830 -- DBH to BW: did we? I thought there were arguments that we should 831 -- not work with the limits of UDP, since other transports 832 -- are now officially supported. If I write an engine that 833 -- has a larger buffer, and use a transport that can handle 834 -- the larger size, why artficially limit it? The type can 835 -- handle the larger number; why impose unnecessary limits? 836 SYNTAX Integer32 (484..65507) 837 MAX-ACCESS read-only 838 STATUS current 839 DESCRIPTION "The maximum length in octets of an SNMP message 840 which this SNMP engine can send or receive and 841 process, determined as the minimum of the maximum 842 message size values supported among all of the 843 transports available to and supported by the engine. 844 " 845 -- From BW to DBH: How do you like this (picked it from RFC1910): 846 -- I think it is only meant to state what it can 847 -- receive!!! 848 -- DBH to BW: I think the one above came from snmpv2*. I think the send 849 -- was included to indictae 850 -- to an enquiring manager how large a getBulk might be 851 -- supported, so a manager didn't send one obviously too large, 852 -- and to reflect that a message might be receivable, but not 853 -- be able to be processed due to resource limitations (such 854 -- as an ASN.1-decoded message being larger than the encoded 855 -- message, or a secured message with a non-sent key that led 856 -- to resource allocation problems...) 857 -- DESCRIPTION "The maximum length in octets of an SNMP message which 858 -- this agent will accept using any transport mapping. 859 -- " 860 ::= { imfEngine 4 } 862 -- From BW to DBH: Was the following decided at the interim? 863 -- We had those defined in USEC doc.... so if we 864 -- do define these protocols here, then I can 865 -- remove them from USEC doc. 866 -- DBH to BW: Not sure if decided; If we want protocols defined 867 -- in a common place, the arch mib should provide the tree. 868 -- I don't object to MD5 and DES being defined in USEC, but 869 -- the arch doc does specify they are expected, so I think 870 -- it treasonable to define here, especially if we want to 871 -- make it mandatory for basic compliance. 872 -- 873 -- The IMF IETF-Standard Authentication Protocols Group 874 -- 876 imfAuthProtocols OBJECT IDENTIFIER ::= { imfAdmin 1 } 878 imfNoAuthProtocol OBJECT IDENTIFIER ::= { imfAuthProtocols 1 } 880 imfAuthMD5Protocol OBJECT IDENTIFIER ::= { imfAuthProtocols 2 } 881 DBH to BW: should we have a description of this object to make it 882 meaningful? ditto for DES below. 884 -- 885 -- The IMF IETF-Standard Privacy Protocols Group 886 -- 888 imfPrivProtocols OBJECT IDENTIFIER ::= { imfAdmin 2 } 890 imfNoPrivProtocol OBJECT IDENTIFIER ::= { imfPrivProtocols 1 } 892 imfDESPrivProtocol OBJECT IDENTIFIER ::= { imfPrivProtocols 2 } 894 -- conformance information 896 imfMIBCompliances 897 OBJECT IDENTIFIER ::= { imfMIBConformance 1 } 898 imfMIBGroups 899 OBJECT IDENTIFIER ::= { imfMIBConformance 2 } 901 -- compliance statements 903 imfMIBCompliance MODULE-COMPLIANCE 904 STATUS current 905 DESCRIPTION "The compliance statement for SNMP engines which 906 implement the IMF MIB. 907 " 908 MODULE -- this module 909 MANDATORY-GROUPS { 910 imfEngineBasicGroup 911 } 912 ::= { imfMIBCompliances 1 } 914 -- units of conformance 916 imfEngineBasicGroup OBJECT-GROUP 917 OBJECTS { 918 snmpEngineID, 919 snmpEngineMaxMessageSize, 920 snmpEngineBoots, 921 snmpEngineTime 922 } 923 STATUS current 924 DESCRIPTION "A collection of objects for identifying and 925 determining the configuration limits of an 926 SNMP agent. 927 " 928 ::= { imfMIBGroups 1 } 930 -- DBH to BW: should the tree for registering protocols be in basicGroup? 931 -- I thouhgt we had consensus that user-based security was required 932 -- as a minimum. No? 934 END 935 7. Model Design Requirements 937 The basic design elements come from SNMPv2u and SNMPv2*, as 938 described in RFCs 1909-1910, and from a set of internet drafts. 939 these are the two most popular de facto "administrative framework" 940 standards that include security and access control for SNMPv2. 942 SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based 943 on communities to provide trivial authentication and access control. 944 SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed 945 to fit into this architecture, and modified versions of SNMPv1 and 946 SNMPv2c Frameworks could be fit into this architecture, but this 947 document does not provide guidelines for that coexistence. 949 Within any subsystem model, there should be no reference to any 950 specific model of another subsystem, or to data defined by a specific 951 model of another subsystem. 953 Transfer of data between the subsystems is deliberately described as a fixed 954 set of abstract data elements and primitive functions which can be overloaded 955 to satisfy the needs of multiple model definitions. 957 Documents which define models to be used within this architecture are constrained 958 to using the abstract data elements for transferring data between subsystems, 959 possibly defining specific mechanisms for converting the abstract data into 960 model-usable formats. This constraint exists to allow subsystem and model 961 documents to be written recognizing common borders of the subsystem and model. 962 Vendors are not constrained to recognize these borders in their implementations. 964 The architecture defines certain standard services to be provided 965 between subsystems, and the architecture defines abstract data 966 elements to transfer the data necessary to perform the services. 968 Each model definition for a subsystem must support the standard service 969 interfaces, but whether, or how, or how well, it performs the service 970 is defined by the model definition. 972 7.1. Security Model Design Requirements 974 7.1.1. Threats 976 Several of the classical threats to network protocols are applicable 977 to the network management problem and therefore would be applicable 978 to any security model used in an Internet Management Framework. Other 979 threats are not applicable to the network management problem. This 980 section discusses principal threats, secondary threats, and threats 981 which are of lesser importance. 983 The principal threats against which any security model used within 984 this architecture should provide protection are: 986 Modification of Information 987 The modification threat is the danger that some unauthorized 988 entity may alter in-transit SNMP messages generated on behalf 989 of an authorized security-identity in such a way as to effect 990 unauthorized management operations, including falsifying the 991 value of an object. 993 Masquerade 994 The masquerade threat is the danger that management operations 995 not authorized for some security-identity may be attempted by 996 assuming the identity of another security-identity that has the 997 appropriate authorizations. 999 Message Stream Modification 1000 The SNMPv3 protocol is typically based upon a connectionless 1001 transport service which may operate over any subnetwork service. 1002 The re-ordering, delay or replay of messages can and does occur 1003 through the natural operation of many such subnetwork services. 1004 The message stream modification threat is the danger that messages 1005 may be maliciously re-ordered, delayed or replayed to an extent 1006 which is greater than can occur through the natural operation of a 1007 subnetwork service, in order to effect unauthorized management 1008 operations. 1010 Disclosure 1011 The disclosure threat is the danger of eavesdropping on the 1012 exchanges between SNMP engines. Protecting against this threat 1013 may be required as a matter of local policy. 1015 There are at least two threats against which a security model used 1016 by a framework within this architecture need not protect. 1018 Denial of Service 1019 A security model need not attempt to address the broad range of 1020 attacks by which service on behalf of authorized users is denied. 1021 Indeed, such denial-of-service attacks are in many cases 1022 indistinguishable from the type of network failures with which any 1023 viable network management protocol must cope as a matter of 1024 course. 1026 Traffic Analysis 1027 A security model need not attempt to address traffic analysis 1028 attacks. Many traffic patterns are predictable - agents may be 1029 managed on a regular basis by a relatively small number of 1030 management stations - and therefore there is no significant 1031 advantage afforded by protecting against traffic analysis. 1033 7.1.2. Security Processing 1035 Received messages must be validated by a model of the security 1036 subsystem. Validation includes authentication and privacy processing 1037 if needed, but it is explicitly allowed to send messages which do 1038 not require authentication or privacy. 1040 A received message will contain a specified Level of Security to be 1041 used during processing. All messages requiring privacy must also 1042 require authentication. 1044 A security model specifies rules by which authentication and privacy 1045 are to be done. A model may define mechanisms to provide additional 1046 security features, but the model definition is constrained to using 1047 (possibly a subset of) the abstract data elements defined in this 1048 document for transferring data between subsystems. 1050 Each Security model may allow multiple security mechanisms to be used 1051 concurrently within an implementation of the model. Each Security model 1052 defines how to determine which protocol to use, given the LoS and the 1053 security parameters relevant to the message. Each Security model, with 1054 its associated protocol(s) defines how the sending/receiving entities 1055 are identified, and how secrets are configured. 1057 Authentication and Privacy protocols supported by security models 1058 are uniquely identified using Object Identifiers. IETF standard 1059 protocol for authentication or privacy should have an identifier 1060 defined within the ImfAuthenticationProtocols or ImfPrivacyProtocols 1061 subtrees. Enterprise-specific protocol identifiers should be defined 1062 within the enterprise subtree. 1064 For privacy, the Security model defines what portion of the message 1065 is encrypted. 1067 The persistent data used for security should be SNMP-manageable, but 1068 the Security model defines whether an instantiation of the MIB is a 1069 conformance requirement. 1071 Security models are replaceable within the security subsystem. Multiple 1072 Security model Implementations may exist concurrently within an engine. 1073 The number of Security models defined by the SNMP community should 1074 remain small to promote interoperability. It is required that an 1075 implementation of the User-Based Security model be used in all 1076 engines to ensure at least a minimal level of interoperability. 1078 7.1.3. validate the security-stamp in a received message 1080 given a message, the MMS, LoS, and the security parameters from that 1081 message, verify the message has not been altered, and authenticate 1082 the identification of the security-identity for whom the message was 1083 generated. 1085 If encrypted, decrypt the message 1087 Additional requirements may be defined by the model, and additional 1088 services provided by the model, but the model is constrained to use 1089 only the defined abstract data elements for transferring data between 1090 subsystems. Implementations are no so constrained. 1092 return a MIID identifying the security-identity for whom 1093 the message was generated and return the portions of the message 1094 needed for further processing: 1095 a PDU - a PDU containing varbinds and a verb according to 1096 the rules of the Local Processing model to be used. 1097 LoS - the level of security required. The same level of 1098 security must also be used during application of access 1099 control. 1100 MMS - the maximum size of a message able to be generated 1101 by this engine for the destination agent. 1102 PDU-MMS - the maximum size of a PDU to be included in a 1103 response message, given the amount of 1104 reserved space in the message for the anticipated 1105 security parameters. 1107 7.1.4. Security Identity 1109 Different security models define identifiers which represent some 1110 which somehow exists, and is capable of using SNMP. 1111 The may be person, or a network-management platform, or 1112 an aggregate of persons, or an aggregation of persons and devices, 1113 or some other abstraction of entities that are recognized as 1114 being able to use SNMP-defined services. 1116 This document will refer to that abstraction as a security-identity. 1118 7.1.5. Model Dependent Identifier 1120 Each Security model defines how security-identities are identified 1121 within the model, i.e. how they are named. Model-dependent identifiers 1122 must be unique within the model. The combination of engineID, 1123 securityModel, and the correct model-dependent identifier can be 1124 used to uniquely identify a security-identity. 1126 For example, David Harrington may be represented on a particular 1127 engine by multiple security models - as the user "davidh", the 1128 community "david", and the foobar "david". It is legal to use 1129 "david" in more than one model, since uniqueness is only guaranteed 1130 within the model, but there cannot be two "david" communities. 1131 The combination of the engineID, the model, and the user 1132 "davidh" uniquely identifies the security-entity David Harrington. 1134 7.1.6. Model Independent Identifier 1136 It is desirable to be able to refer to a security-entity using a human 1137 readable identifier, such as for audit trail entries. 1138 Therefore, each Security model is required to define a mapping between 1139 a model-dependent identifier and an identifier restricted to a human 1140 readable character set. This identifier is called a MIID. 1142 The type of a MIID is a human-readable OCTET STRING following the 1143 conventions of the SnmpAdminString TEXTUAL-CONVENTION, defined below. 1145 The combination of engineID and securityModel and MIID can be used as a 1146 globally-unique identifier for a security-identity. 1148 It is important to note that since the MIID may be accessible outside 1149 the engine, care must be taken to not disclose sensitive data, such 1150 as by including passwords in open text in the MIID. 1152 7.1.5. Security MIBs 1154 Each Security model defines the MIB modules required for security 1155 processing, including any MIB modules required for the security 1156 mechanism(s) supported. The MIB modules must be defined concurrently 1157 with the procedures which use the MIB module. The MIB modules are 1158 subject to normal security and access control rules. 1160 The mapping between the model-dependent identifier and the MIID 1161 must be able to be determined using SNMP, if the model-dependent 1162 MIB is instantiated and access control policy allows. 1164 7.1.6. Security State Cacheing 1166 For each message received, the security subsystem caches the state information 1167 such that a response message can be generated using the same security 1168 state information, even if the security portion of the Local Configuration 1169 Datastore is altered between the time of the incoming request and the 1170 outgoing response. 1172 The Orangelet subsystem has the responsibility for explicitly releasing 1173 the cached data. To enable this, an abstract state_reference data element 1174 is passed from the security subsystem to the message processing and control 1175 subsystem, which passes it to the orangelet subsystem. 1177 The cached security data must be implicitly released via the generation of a 1178 response, or explicitly released by using the state_release() primitive: 1180 state_release( state_reference ) 1182 7.2. MessageEngine and Message Processing and Control Model Requirements 1184 A messageEngine may contain multiple version-specific Message Processing and 1185 Control models. 1187 Within any version-specific Message Processing and Control model, there may be 1188 an explicit binding to a particular security model but there should be no 1189 reference to any data defined by a specific security model. there should be 1190 no reference to any specific Orangelet model, or to any data defined by a 1191 specific Orangelet model; there should be no reference to any specific Access 1192 Control model, or to any data defined by a specific Access Control model. 1194 The Message Processing and Control model must always (conceptually) 1195 pass the complete PDU, i.e. it never forwards less than the complete 1196 list of varbinds. 1198 7.2.1. Receiving an SNMP Message from the Network 1200 Upon receipt of a message from the network, the messageEngine will, 1201 in an implementation-defined manner, establish a mechanism for coordinating 1202 all processing regarding this received message, e.g. it may assign a "handle" 1203 to the message. 1204 DBH: It is no longer valid that the MPC coordinates all processing. But it 1205 still needs to match requests and responses. how does an incoming request get 1206 matched to the outgoing response? 1208 A Message Processing and Control model will specify how to determine the values 1209 of the global data (MMS, the securityModel, the LoS), and the security 1210 parameters block. The Message Processing and Control will call the security 1211 model to provide security processing for the message using the primitive: 1213 processMsg( globalData, securityParameters, wholeMsg, wholeMsgLen ) 1215 The Security model, after completion of its processing, will return to 1216 the Message Processing and Control model the extracted information, using 1217 the returnProcess() primitive: 1219 returnProcess( scopedPDUmms, MIID, cachedSecurityData, scopedPDU, statusCode ) 1221 7.2.2. Send SNMP messages to the network 1223 The Message Processing and Control model will pass a PDU, the 1224 MIID, and all global data to be included in the message to 1225 the Security model using the following primitives: 1227 For requests and notifications: 1229 generateRequestMessage( globalData, scopedPDU, MIID, engineID ) 1231 DBH: why do we need engineID? isn't that implicit? 1233 For response messages: 1235 generateResponseMessage( globalData, scopedPDU, MIID, cachedSecurityData ) 1237 The Security model will construct the message, and return the completed 1238 message to the messageEngine using the returngenerate() primitive: 1240 returnGenerate( wholeMsg, wholeMsglen, statusCode ) 1241 The messageEngine will send the message to the desired address using the 1242 appropriate transport. 1244 7.2.3. Generate a Request or Notification Message for an Orangelet 1246 The messageEngine will receive a request for the generation of an SNMP message 1247 from an orangelet via the send_pdu primitive: 1249 send_pdu( transportDomain, transportAddress, snmpVersion, 1250 LoS, securityModel, MIID, contextEngineID, 1251 contextName, PDU, 1253 The messageEngine checks the verb in the PDU to determine if it is a message 1254 which may receive a response, and if so, caches the msgID of the generated 1255 message and the associated orangelet. 1257 The messageEngine will generate the message according to the process described 1258 in 7.2.2. 1260 7.2.4. Forward Received Response Message to an Orangelet 1262 The Message Processing and Control will receive the SNMP message 1263 according to the process described in 7.2.1. 1265 The Message Processing and Control will determine which orangelet is 1266 awaiting a response, using the msgID and the cached information from 1267 step 7.2.3 1269 The messageEngine matches the msgID of an incoming response to the cached 1270 msgIDs of messages sent by this messageEngine, and forwards the response to the 1271 associated Orangelet using the process_pdu() primitive: 1273 process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS, 1274 securityModel, MIID, state-reference ) 1276 7.2.5. Forward Received Request or Notification Message to an Orangelet 1278 The messageEngine will receive the SNMP message according to the process 1279 described in 7.2.1. 1281 The messageEngine will look into the scopedPDU to determine the contextEngineID, 1282 then determine which orangelet has registered to support that contextEngineID, 1283 and forwards the request or notification to the registered Orangelet using the 1284 process_pdu() primitive: 1286 process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS, 1287 securityModel, MIID, state-reference ) 1288 7.2.6. Generate a Response Message for an Orangelet 1290 The messageEngine will receive a request for the generation of an SNMP response 1291 message from an orangelet via the return_pdu primitive: 1293 return_pdu( contextEngineID, contextName, LoS, MIID, state_reference, 1294 PDU, PDU-MMS, status_code ) 1296 The messageEngine will generate the message according to the process described 1297 in 7.2.2. 1299 7.3. Orangelet Model Design Requirements 1301 Within an Orangelet model, there may be an explicit binding to a specific 1302 SNMP message version, i.e. a specific Message Processing and Control model, 1303 and to a specific Access Control model, but there should be no reference to 1304 any data defined by a specific Message Processing and Control model or Access 1305 Control model. 1307 Within an Orangelet model, there should be no reference to any 1308 specific Security model, or any data defined by a specific Security 1309 model. 1311 An Orangelet determines whether explicit or implicit access control 1312 should be applied to the operation, and, if access control is needed, 1313 which Access Control model should be used. 1315 An orangelet has the responsibility to define any MIB modules used 1316 to provide orangelet-specific services. 1318 Orangelets interact with the messageEngine to initiate messages, receive 1319 responses, receive asynchronous messages, and send responses. 1321 7.3.1. Orangelets that Initiate Messages 1323 Orangelets may request that the messageEngine send messages containing SNMP 1324 polling requests or notifications using the send_pdu() primitive: 1326 send_pdu( transportDomain, transportAddress, snmpVersion, 1327 LoS, securityModel, MIID, contextEngineID, 1328 contextName, PDU, 1330 [DBH: I rearranged these parameters into groups of related data organized 1331 roughly by order of locality - transport/engine/contextEngine/PDU.] 1333 If it is desired that a message be sent to multiple targets, it is the 1334 reponsibility of the orangelet to provide the iteration. 1336 The messageEngine assumes necessary access control has been applied 1337 to the PDU, and provides no access control services. 1339 The messageEngine looks at the verb, and for operations which will elicit a 1340 response, the msgID and the associated orangelet are cached. 1342 7.3.2. Orangelets that Receive Responses 1344 The messageEngine matches the msgID of an incoming response to the cached 1345 msgIDs of messages sent by this messageEngine, and forwards the response to the 1346 associated Orangelet using the process_pdu() primitive: 1348 process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS, 1349 securityModel, MIID, state-reference ) 1351 DBH: should the MPC release the state_reference when it receives a response? 1352 There isn't much reason to force the orangelet to handle this if the MPC 1353 already knows it is a response message, i.e. the end of a transaction. 1355 7.3.3. Orangelets that Receive Asynchronous Messages 1357 When a messageEngine receives a message that is not the response to a request 1358 from this messageEngine, it must determine to which Orangelet the message 1359 should be given. 1361 An Orangelet that wishes to receive asynchronous messages registers 1362 itself with the messageEngine using the registration primitive. 1363 An Orangelet that wishes to stop receiving asynchronous messages 1364 should un-register itself with the messageEngine. 1366 register_contextEngineID ( contextEngineID ) 1367 unregister_contextEngineID ( contextEngineID ) 1369 Only one registration per contextEngineID is permitted at the same 1370 time. Duplicate registrations are ignored. 1372 [DBH: there is no provision for an error for this. Is the second 1373 just ignored?] 1375 All asynchronously received messages referencing a registered contextEngineID 1376 will be sent to the orangelet which registered to support that contextEngineID. 1377 This includes incoming requests, incoming notifications, and proxies. 1379 It forwards the PDU to the registered Orangelet, using the process_pdu() 1380 primitive: 1382 process_pdu( contextEngineID, contextName, PDU, PDU-MMS, 1383 LoS, securityModel, MIID, state_reference ) 1385 7.3.4. Orangelets that Send Responses 1387 Request operations require responses. These operations include Get requests, 1388 set requests, and inform requests. An Orangelet sends a response via the 1389 return_pdu primitive: 1391 return_pdu( contextEngineID, contextName, LoS, MIID, state_reference, 1392 PDU, PDU-MMS, status_code ) 1394 The contextEngineID, contextName, LoS, MIID, and state_reference parameters 1395 are from the initial process_pdu() primitive. The PDU and status_code are 1396 the results of processing. 1398 DBH: in the v2adv approach, a handle was passed so the messageEngine 1399 could match the response to the incoming request. How is it done now? 1401 7.4. Access Control Model Design Requirements 1403 An Access Control model must determine whether the specified 1404 MIID is allowed to perform the requested operation on 1405 a specified managed object. The Access Control model specifies the 1406 rules by which access control is determined. 1408 A model may define mechanisms to provide additional processing 1409 features, but is constrained to using the abstract data elements 1410 defined in this document for transferring data between subsystems. 1412 The persistent data used for access control should be manageable 1413 using SNMP, but the Access Control model defines whether an 1414 instantiation of the MIB is a conformance requirement. 1416 8. Security Consideration 1418 This document describes how a framework can use a Security model 1419 and a Local Processing model to achieve a level of security for 1420 network management messages and controlled access to data. 1422 The level of security provided is determined by the specific Security 1423 model implementation(s) and the specific Local Processing model 1424 implementation(s) incorporated into this framework. 1426 Orangelets have access to data which is not secured. Orangelets 1427 should take reasonable steps to protect the data from disclosure. 1429 It is the responsibility of the purchaser of a management framework 1430 implementation to ensure that: 1431 1) an implementation of this framework is fully compliant with 1432 the rules defined by this architecture, 1433 2) the implementation of the Security model complies with the 1434 rules of the Security model, 1435 3) the implementation of the Local Processing model complies 1436 with the rules of the Local Processing model, 1437 4) the implementation of associated orangelets comply 1438 with the rules of this framework relative to orangelets, 1439 5) the Security model of the implementation(s) incorporated into 1440 the framework satisfy the security needs of the organization, 1441 6) the Local Processing model of the implementation(s) incorporated 1442 into the framework satisfy the access control policies of the 1443 organization, 1444 7) the implementation of the Security model protects against 1445 inadvertently revealing security secrets in its design of 1446 implementation-specific data structures, 1447 8) the implementation of the Local Processing model protects against 1448 inadvertently revealing configuration secrets in its design of 1449 implementation-specific data structures, 1450 9) and implementation of the orangelets protect security and 1451 access control configuration secrets from disclosure. 1453 9. Glossary 1454 10. References 1456 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of 1457 Management Information for TCP/IP-based internets", STD 16, RFC 1458 1155, May 1990. 1460 [RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple 1461 Network Management Protocol", RFC 1157, University of Tennessee 1462 at Knoxville, Performance Systems International, Performance 1463 International, and the MIT Laboratory for Computer 1464 Science, May 1990. 1466 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 1467 STD 16, RFC 1212, March 1991. 1469 [RFC1445] Galvin, J., and McCloghrie, K., "Administrative Model for 1470 version 2 of the Simple Network Management Protocol (SNMPv2)", 1471 RFC 1445, Trusted Information Systems, Hughes LAN Systems, 1472 April 1993. 1474 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1475 Rose, M., and S., Waldbusser, "Introduction to 1476 Community-based SNMPv2", RFC 1901, January 1996. 1478 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1479 Rose, M., and S., Waldbusser, "Structure of Management 1480 Information for Version 2 of the Simple Network Management 1481 Protocol (SNMPv2)", RFC 1905, January 1996. 1483 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1484 and S. Waldbusser, "Textual Conventions for Version 2 of the Simple 1485 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1487 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1488 and S., Waldbusser, "Conformance Statements for Version 2 of the 1489 Simple Network Management Protocol (SNMPv2)", RFC 1904, 1490 January 1996. 1492 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1493 Rose, M., and S., Waldbusser, "Protocol Operations for 1494 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1495 RFC 1905, January 1996. 1497 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1498 Rose, M., and S. Waldbusser, "Transport Mappings for 1499 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1500 RFC 1906, January 1996. 1502 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1503 Rose, M., and S. Waldbusser, "Management Information Base for 1504 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1505 RFC 1907 January 1996. 1507 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1508 Rose, M., and S. Waldbusser, "Coexistence between Version 1 1509 and Version 2 of the Internet-standard Network Management 1510 Framework", RFC 1908, January 1996. 1512 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 1513 for SNMPv2", RFC1909, February 1996 1515 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 1516 RFC1910, February 1996 1518 11. Editor's Addresses 1520 Co-editor: Bert Wijnen 1521 IBM T.J. Watson Research 1522 postal: Schagen 33 1523 3461 GL Linschoten 1524 Netherlands 1525 email: wijnen@vnet.ibm.com 1526 phone: +31-348-412-498 1528 Co-editor Dave Harrington 1529 Cabletron Systems, Inc 1530 postal: Post Office Box 5005 1531 MailStop: Durham 1532 35 Industrial Way 1533 Rochester NH 03867-5005 1534 email: dbh@cabletron.com 1535 phone: 603-337-7357 1537 12. Acknowledgements 1539 This document builds on the work of the SNMP Security and 1540 Administrative Framework Evolution team, comprised of 1542 David Harrington (Cabletron Systems Inc.) 1543 Jeff Johnson (Cisco) 1544 David Levi (SNMP Research Inc.) 1545 John Linn (Openvision) 1546 Russ Mundy (Trusted Information Systems) chair 1547 Shawn Routhier (Epilogue) 1548 Glenn Waters (Nortel) 1549 Bert Wijnen (IBM T.J. Watson Research) 1551 Table of Contents 1553 0. Issues 3 1554 0.1. Issues to be resolved 3 1555 0.2. Change Log 3 1556 1. Introduction 5 1557 1.1. A Note on Terminology 5 1558 2. Overview 6 1559 3. An Evolutionary Architecture - Design Goals 7 1560 3.1. Encapsulation 7 1561 3.2. Cohesion 7 1562 3.3. Hierarchical Rules 8 1563 3.4. Coupling 8 1564 4. Abstract Functionality 10 1565 4.1. The messageEngine 10 1566 4.1.1. Transport Mappings 10 1567 4.1.2. SNMP-Based Message Formats 10 1568 4.1.3. The Interface to Orangelets 11 1569 4.1.4. Protocol Instrumentation 11 1570 4.2. Security 11 1571 4.3. Orangelets 11 1572 4.4.1. Structure of Management Information 12 1573 4.4.2. Textual Conventions 12 1574 4.4.3. Conformance Statements 12 1575 4.4.4. Protocol Operations 12 1576 4.5. Access Control 13 1577 4.6. Coexistence 13 1578 5. Abstract Data Elements of the Architecture 14 1579 5.1. engineID 14 1580 5.2. SecurityIdentity 14 1581 5.3. Model Independent Identifier (MIID) 14 1582 5.4. Level of Security 14 1583 5.5. Contexts 15 1584 5.6. ContextName 15 1585 5.7. ContextEngineID 15 1586 5.8. Naming Scope 15 1587 5.9. Scoped-PDU 15 1588 5.10. PDU-MMS 15 1589 5.11. Local Configuration Datastore 15 1590 5.11.1. Security Portion of the Local Configuration Datastore 16 1591 5.11.2. Orangelet Portion of the Local Configuration Datastore 16 1592 5.11.3. Access Control Portion of the Local Configuration Datastore 16 1593 5.12. Groups 16 1594 6. Definition of Managed Objects for Internet Management Frameworks 17 1595 7. Model Design Requirements 24 1596 7.1. Security Model Design Requirements 24 1597 7.1.1. Threats 24 1598 7.1.2. Security Processing 25 1599 7.1.3. validate the security-stamp in a received message 26 1600 7.1.4. Security Identity 27 1601 7.1.5. Model Dependent Identifier 27 1602 7.1.6. Model Independent Identifier 27 1603 7.1.5. Security MIBs 28 1604 7.1.6. Security State Cacheing 28 1605 7.2. MessageEngine and Message Processing and Control Model Requirements 28 1606 7.2.1. Receiving an SNMP Message from the Network 29 1607 7.2.2. Send SNMP messages to the network 29 1608 7.2.3. Generate a Request or Notification Message for an Orangelet 30 1609 7.2.4. Forward Received Response Message to an Orangelet 30 1610 7.2.5. Forward Received Request or Notification Message to an Orangelet 30 1611 7.2.6. Generate a Response Message for an Orangelet 31 1612 7.3. Orangelet Model Design Requirements 31 1613 7.3.1. Orangelets that Initiate Messages 31 1614 7.3.2. Orangelets that Receive Responses 32 1615 7.3.3. Orangelets that Receive Asynchronous Messages 32 1616 7.3.4. Orangelets that Send Responses 32 1617 7.4. Access Control Model Design Requirements 33 1618 8. Security Consideration 34 1619 9. Glossary 35 1620 10. References 36 1621 11. Editor's Addresses 38 1622 12. Acknowledgements 39