Security and SNMPv3

Motivations for SNMPv3

In all of our packet captures of SNMP messages, and in examining the message format we saw that there is a field for a Community string, which I mentioned was a poor excuse for a security model. You saw in the packet captures that the Community string is a plain text string, which means that anyone who captures the packet can view it. The concept of a community-based framework, which was used in SNMPv1 and SNMPv2, was that members of the same community can communicate. An agent or an NMS can belong to more than one community. Further, each community can have a level of access defined to it (read- only, read-write, etc.) and can have a MIB view defined to it. The MIB view defines what portions of the MIB tree are accessible to a particular community. As an example, you can go back and take a look at my definition of "public" as the read-only community and "reedrite" as the read-write community on my Windows agent.

With SNMPv3 we have security management, providing authentication (stronger than a community string) and privacy at the message level. The ability to define access levels and MIB views is retained. In addition to this most important and needed functionality, SNMPv3 provides a framework for the existing versions of SNMP and for future development. There was an attempt to minimize the impact on existing implementations, which was important because of the huge number of agents out there that support the older versions. SNMPv3 also defined modularization of documentation and architecture - basically making order of what started out simple and became not so simple, after all. The PDU format for SNMPv3 is the as for SNMPv2, but we will see that there are additional headers for the security function and for other definitions. The terminology of SNMPv3 has changed (and has increased the total amount of terminology). For example, both agents and managers are referred to as "SNMP entities". Frankly, I'm not sure what benefit the typical user has from all the new terminology that was introduced.

Our main interest in this tutorial is the security framework, as the architecture and documentation aspects are mostly of importance to developers, who would turn to the RFCs and more comprehensive documentation. Therefore, the reader who is interested in the documentation architecture and modularity aspects are referred to the RFCs.

The full collection of RFCs for SNMPv3 can be found at this great website. I brought you to the section for the RFCs, but if you scroll up, you'll see you have links to other tutorials, and even downloadable books. The site has loads of links to all sorts of SNMP resources.

The SNMPv3 Message Format

The SNMPv3 message has four groups of data:

  1. Version: This group consists of a single field, the version number, which is in the same position as the version field in SNMPv1 and v2.
  2. Global data: This group contains administrative parameters for the message.
  3. Security parameters: These parameters are used for the security model and their values depend upon the security model specified in the header data.
  4. Scoped PDU: This section, sent either plaintext or encrypted, contains an SNMPv2c PDU preceded by context information. The concept of context will be explained shortly.

The message format, as defined in RFC 3412, is shown in Figure 67.

Figure 67: SNMPv3 Message Format

The definitions of each of the fields are as follows:

msgVersion - This is the SNMP version number of the message format. As mentioned above, this field is in the same location as it was for previous versions of SNMP, so backward compatibility is provided. It is set to 3 for SNMPv3.

msgID - This is an ID associated withe the message and is used to coordinate request messages and responses. Remember that the PDU contains a request ID. But the PDU might be encrypted, and even if decryption fails, the message must be identified.

msgMaxSize - This value indicates the maximum message size supported by the sender of the message.

msgFlags - This field contains several bit fields that control processing of the message, and set the security level. At the end of the previous chapter I mentioned the Report-PDU. The reportableFlag, if used, is one of the factors that determines if a Report-PDU is sent. RFC 3412 has more details on use of the Report-PDU.

msgSecurityModel - Because SNMPv3 supports multiple security models, we need to identify which security model was used by the sender to generate the message, and therefore, which security model MUST be used by the receiver to perform security processing for the message.

msgSecurityParameters - This field is used for communication between the security model modules in the sending and receiving SNMP entities. The data in this field is used exclusively by the security model, which defines the contents and format of the field, which is defined in the RFC simply as an OCTET STRING.

contextEngineID and contextName - Because a management entity can be responsible for multiple copies of the same MIB, the concept of context was devised. For example, a modular device, such as a switch, might have multiple modules, each with multiple ports. Each module implements the bridge MIB, and the port numbering is identical for each one. By using a context, SNMPv3 extends the indexing of a table (or scalar objects), so that multiple instances of a table can be differentiated and handled by the same agent. Each module would be treated as a context with a contextEngineID and contextName.

data - This is the PDU.

SNMPv3 Packet Capture

Alas, unless you have an agent that supports SNMPv3 (you can use NetSNMP to install such an agent, if you wish, but I will not walk you through that - it is beyond the scope of this tutorial, though I highly recommend it for the motivated), you will not be able to easily capture SNMPv3 messages. However, here is a capture file that you can take a look at with Wireshark. There is a GetRequest and a Report message, each sent in plaintext. This is a subset of a capture file that I found from the Electrical Engineering and Computer Science department at Jacobs University in Germany. I'll leave it to you to compare the results of the capture to the message format above. At the end of the next section, on SNMPv3 security, I'll tell you another link to download another capture file.

The SNMPv3 Security Model

The security model provides authentication and privacy mechanisms. The security model is a User-Based Security Model (USM), defined in RFC 3414. USB is one of those fancy acronyms dreamt up when all they mean is a traditional user-name concept that we are all familiar with. Authentication uses MD5-96 or SHA-96 algorithms to authenticate users. Privacy relies on DES for encryption/decryption, though other algorithms can be supported. The actual security algorithms are beyond the scope of this tutorial. They are not specific to SNMP and are commonly used in providing data security in network applications.

The access control system permits definition of access level and MIB view for each user defined. Again, the authors of the protocol defined a snazzy acronym for this - VACM, to mean View-based Access Control Model, which is defined in RFC 3415. So, for example, if you want to a particular user to have read-only access to only the interface group, this would be defined, and if a user did a "MIB walk", s/he would get to the "end of MIB" when sending a get-next on the last instance of the last object in the interface group.

VACM retains the concept of a "community" from the earlier SNMP versions, but it calls it a "group" instead. VACM assumes that a user has already been authenticated, and all elements in a group have the same access rights.

Figure 68 shows a simplified example of a VACM Access Table.

Figure 68: VACM Access Table

A MIB view permitted to a particular manager could, of course, be more complex - it could be any subset of the total MIB tree being managed.

Now that you have some background on the security model, you might want to take a look at another nifty packet capture. This file is from the collection of sample captures on the Wireshark wiki, where, if you select SNMP (number 11) in the list, you'll find the details about the file entitled snmp_usm.pcap, which you can download there (or from the direct link that I just provided). If you are good with security algorithms, you might even be able to decrypt those encrypted messages! (The passwords are provided.)

Transport Security Model

Apparently, the USM is not so simple. To use passwords (or secret keys), you need a key-management system, and implementing such a system for the purposes of SNMP is daunting. Why do I say this? Well, it is actually not me who said it. The authors of a set of three RFCs, RFC 5590, RFC 5591, and RFC 5592 stated that the motivation for the Transport Security Model is that "Operators have reported that having to deploy another user and key-management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3."

The Transport Security Model offers another option, which enables use of other existing security mechanisms, namely TLS and SSH. The set of RFCs defined how to map these existing security mechanisms into the SNMP architecture and to maintain interoperability with existing systems. Here is an interesting presentation about comparisons of running SNMPv3 with the USM and SNMP over SSH or TLS. (You might also want to take a look at this earlier presentation.) Since I am writing this just as the RFCs were issued, it is too soon to tell whether operators will find that this new model is preferable or easier to implement. It will, of course, depend a lot upon the ease of use of SNMP applications that are built around this new security model.

Interactive Demo

As the last activity (and item) in this tutorial (did you really make it this far?), you can return to the SimpleWeb Demo that you saw several times before, if you've been going through this whole tutorial. In the SNMPv3 part of the demo, you can do the same activities you did before with SNMPv2, but now you can add some security aspects to your activity. The following information is given on their exercises page: Security name = demo, MD5 key = abcdefghi, DES key = abcdefghi. Remember that the getNext and getBulk do not really work according to spec on the table, but have a good time, anyway!

This ends our hands-on SNMP tutorial. I sure hope you've learned a lot from it and enjoyed it, too! I welcome your comments and suggestions. Just drop me a note from the Contact the Dean box on the RAD University Home Page. If your comment is too long for the form, send me a brief comment asking for me to contact you. I will be happy to respond to you and then to hear all your comments.

Previous

www.rad.com