Network Working Group U. Blumenthal Request for Comments: 2264 IBM T. J. Watson Research Category: Standards Track B. Wijnen IBM T. J. Watson Research January 1998 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. Abstract This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. Table of Contents 1. Introduction 3 1.1. Threats 4 1.2. Goals and Constraints 5 1.3. Security Services 6 1.4. Module Organization 7 1.4.1. Timeliness Module 7 1.4.2. Authentication Protocol 8 1.4.3. Privacy Protocol 8 1.5. Protection against Message Replay, Delay and Redirection 8 1.5.1. Authoritative SNMP engine 8 1.5.2. Mechanisms 8 1.6. Abstract Service Interfaces. 10 1.6.1. User-based Security Model Primitives for Authentication 11 1.6.2. User-based Security Model Primitives for Privacy 11 2. Elements of the Model 12 2.1. User-based Security Model Users 12 Blumenthal & Wijnen Standards Track [Page 1] RFC 2264 USM for SNMPv3 January 1998 2.2. Replay Protection 13 2.2.1. msgAuthoritativeEngineID 13 2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime 14 2.2.3. Time Window 15 2.3. Time Synchronization 15 2.4. SNMP Messages Using this Security Model 16 2.5. Services provided by the User-based Security Model 17 2.5.1. Services for Generating an Outgoing SNMP Message 17 2.5.2. Services for Processing an Incoming SNMP Message 19 2.6. Key Localization Algorithm. 21 3. Elements of Procedure 21 3.1. Generating an Outgoing SNMP Message 22 3.2. Processing an Incoming SNMP Message 25 4. Discovery 30 5. Definitions 31 6. HMAC-MD5-96 Authentication Protocol 45 6.1. Mechanisms 45 6.1.1. Digest Authentication Mechanism 46 6.2. Elements of the Digest Authentication Protocol 46 6.2.1. Users 46 6.2.2. msgAuthoritativeEngineID 47 6.2.3. SNMP Messages Using this Authentication Protocol 47 6.2.4. Services provided by the HMAC-MD5-96 Authentication Module 47 6.2.4.1. Services for Generating an Outgoing SNMP Message 47 6.2.4.2. Services for Processing an Incoming SNMP Message 48 6.3. Elements of Procedure 49 6.3.1. Processing an Outgoing Message 49 6.3.2. Processing an Incoming Message 50 7. HMAC-SHA-96 Authentication Protocol 51 7.1. Mechanisms 51 7.1.1. Digest Authentication Mechanism 51 7.2. Elements of the HMAC-SHA-96 Authentication Protocol 52 7.2.1. Users 52 7.2.2. msgAuthoritativeEngineID 52 7.2.3. SNMP Messages Using this Authentication Protocol 53 7.2.4. Services provided by the HMAC-SHA-96 Authentication Module 53 7.2.4.1. Services for Generating an Outgoing SNMP Message 53 7.2.4.2. Services for Processing an Incoming SNMP Message 54 7.3. Elements of Procedure 54 7.3.1. Processing an Outgoing Message 55 7.3.2. Processing an Incoming Message 55 8. CBC-DES Symmetric Encryption Protocol 56 8.1. Mechanisms 56 8.1.1. Symmetric Encryption Protocol 57 8.1.1.1. DES key and Initialization Vector. 57 8.1.1.2. Data Encryption. 58 8.1.1.3. Data Decryption 59 8.2. Elements of the DES Privacy Protocol 59 Blumenthal & Wijnen Standards Track [Page 2] RFC 2264 USM for SNMPv3 January 1998 8.2.1. Users 59 8.2.2. msgAuthoritativeEngineID 59 8.2.3. SNMP Messages Using this Privacy Protocol 60 8.2.4. Services provided by the DES Privacy Module 60 8.2.4.1. Services for Encrypting Outgoing Data 60 8.2.4.2. Services for Decrypting Incoming Data 61 8.3. Elements of Procedure. 61 8.3.1. Processing an Outgoing Message 61 8.3.2. Processing an Incoming Message 62 9. Intellectual Property 62 10. Acknowledgements 63 11. Security Considerations 64 11.1. Recommended Practices 64 11.2. Defining Users 66 11.3. Conformance 67 12. References 67 13. Editors' Addresses 69 A.1. SNMP engine Installation Parameters 70 A.2. Password to Key Algorithm 71 A.2.1. Password to Key Sample Code for MD5 71 A.2.2. Password to Key Sample Code for SHA 72 A.3. Password to Key Sample Results 73 A.3.1. Password to Key Sample Results using MD5 73 A.3.2. Password to Key Sample Results using SHA 74 A.4. Sample encoding of msgSecurityParameters 74 B. Full Copyright Statement 76 1. Introduction The Architecture for describing Internet Management Frameworks [RFC2261] describes that an SNMP engine is composed of: 1) a Dispatcher 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Security Model described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC2261]. Blumenthal & Wijnen Standards Track [Page 3] RFC 2264 USM for SNMPv3 January 1998 This memo [RFC2264] describes the User-based Security Model as it is used within the SNMP Architecture. The main idea is that we use the traditional concept of a user (identified by a userName) with which to associate security information. This memo describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the authentication protocols and the use of CBC-DES as the privacy protocol. The User-based Security Model however allows for other such protocols to be used instead of or concurrent with these protocols. Therefore, the description of HMAC-MD5-96, HMAC-SHA-96 and CBC-DES are in separate sections to reflect their self-contained nature and to indicate that they can be replaced or supplemented in the future. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Threats Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any SNMP Security Model. Other threats are not applicable to the network management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which this SNMP Security Model should provide protection are: - Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized user in such a way as to effect unauthorized management operations, including falsifying the value of an object. - Masquerade The masquerade threat is the danger that management operations not authorized for some user may be attempted by assuming the identity of another user that has the appropriate authorizations. Two secondary threats are also identified. The Security Model defined in this memo provides limited protection against: - Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between managed agents and a management station. Protecting against this threat may be required as a matter of local policy. Blumenthal & Wijnen Standards Track [Page 4] RFC 2264 USM for SNMPv3 January 1998 - Message Stream Modification The SNMP protocol is typically based upon a connection-less transport service which may operate over any sub-network service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such sub-network services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a sub-network service, in order to effect unauthorized management operations. There are at least two threats that an SNMP Security Model need not protect against. The security protocols defined in this memo do not provide protection against: - Denial of Service This SNMP Security Model does not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable network management protocol must cope as a matter of course. - Traffic Analysis This SNMP Security Model does not attempt to address traffic analysis attacks. Indeed, many traffic patterns are predictable - devices may be managed on a regular basis by a relatively small number of management applications - and therefore there is no significant advantage afforded by protecting against traffic analysis. 1.2. Goals and Constraints Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMP Security Model are as follows. 1) Provide for verification that each received SNMP message has not been modified during its transmission through the network. 2) Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated. 3) Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent. 4) Provide, when necessary, that the contents of each received SNMP message are protected from disclosure. Blumenthal & Wijnen Standards Track [Page 5] RFC 2264 USM for SNMPv3 January 1998 In addition to the principal goal of supporting secure network management, the design of this SNMP Security Model is also influenced by the following constraints: 1) When the requirements of effective management in times of network stress are inconsistent with those of security, the design should prefer the former. 2) Neither the security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or key management protocols). 3) A security mechanism should entail no changes to the basic SNMP network management philosophy. 1.3. Security Services The security services necessary to support the goals of this SNMP Security Model are as follows: - Data Integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non-maliciously. - Data Origin Authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is corroborated. - Data Confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. - Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted. Note that message reordering is not dealt with and can occur in normal conditions too. For the protocols specified in this memo, it is not possible to assure the specific originator of a received SNMP message; rather, it is the user on whose behalf the message was originated that is authenticated. Blumenthal & Wijnen Standards Track [Page 6] RFC 2264 USM for SNMPv3 January 1998 For these protocols, it not possible to obtain data integrity without data origin authentication, nor is it possible to obtain data origin authentication without data integrity. Further, there is no provision for data confidentiality without both data integrity and data origin authentication. The security protocols used in this m