The Simple Times (tm) is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents technical articles and featured columns, along with a standards summary and a list of Internet resources. In addition, some issues contain summaries of recent publications and upcoming events. For information on submissions, see the end of this issue.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an ``as is'' basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available via both electronic mail and hard copy. For information on subscriptions, see the end of this issue.
This article gives an overview of the concepts and security features of the USEC model. The USEC model also defines mechanisms to handle proxy agents that will be covered in a future article in The Simple Times.
The user, a well known paradigm for computer users, is the basis of all protocol interactions in the USEC model. Conceptually, the user model is very analogous to the user-id/password that is used to login to a computer. The user, identified by a userName (the ``user-id'') is used to identify who is accessing information at an agent. A key (the ``password'') is used to ensure that the user is authentic. Optionally, a second key may be used to ensure privacy. The user-id/password model also grants a user-id a set of privileges. Similarly, the USEC model associates a set of access rights with an user.
Implicit in the user-id/password model is that some entity (machine or human) has knowledge of the user-id and password that may be used to login to a particular computer. The USEC model maintains that paradigm in that the shared knowledge of a user must be known to both the entity that wishes to access an SNMPv2 agent and to the agent itself.
The goals and non-goals defined here are, in practice, the same as those defined for the now-historical SNMPv2 party model specified in RFC 1446.
The USEC model defines the use of MD5 as the authentication protocol and the use of DES as the privacy protocol. The keys associated with both the MD5 and DES protocols are 128-bit values. To provide an interface that is more user-friendly than 128-bit keys, USEC model specifies the use of a password to key algorithm as was originally defined by Steve Waldbusser as part of the SNMPv2 party model.
Quality of Service (qoS) is defined as the level of security that is afforded a particular message. The defined qoS levels are:
Time Window is a value that specifies the window of time in which an authenticated message generated on behalf of a user is valid. The same value of the Time Window, 150 seconds, is used for all users.
Local Configuration Datastore (LCD) is a locally defined (conceptual) datastore that holds a set of information about (locally known) SNMPv2 users and other associated information (e.g., access control). Each SNMPv2 entity maintains an LCD. An LCD may potentially be required to hold information about multiple SNMPv2 agent entities (e.g., in a manager that communicates with multiple SNMPv2 agent entities), and as such the agentID should be used to distinguish the information associated with a particular agent entity in the LCD.
An SNMPv2 message is an ASN.1 value with the following syntax:
Message ::=
SEQUENCE {
version
INTEGER { v2u(2) },
parameters
OCTET STRING,
data
CHOICE {
plaintext PDUs,
encrypted OCTET STRING
}
}
The first octet in the parameters component is the model,
where the value 1 refers to that USEC model.
In that case,
the parameters field contains several values encoded in
network-byte order:
A context is termed a local SNMPv2 context if it is realized by an SNMPv2 entity that uses locally-defined mechanisms to access the management information identified by the SNMPv2 context.
The term remote SNMPv2 context is used at an SNMPv2 manager to indicate a SNMPv2 context which is not realized by the local SNMPv2 entity (i.e., the local SNMPv2 entity uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context). The USEC model also defines proxy SNMPv2 contexts.
The combination of an agentID value and a context selector provides for a unique identification of a context within an administrative domain.
When the agent entity detects an error (e.g., the received message has a bad authentication digest) and the qoS indicates that a report may be generated, then after incrementing the appropriate error statistic, a report PDU message is generated. The report is generated with the same user and context as the received message and is sent to the same transport address as the received message. All error reports, except those generated due to a not-in-time-window error condition, are unauthenticated (i.e., qoS is noAuth/noPriv). To allow a management entity to authentically synchronize its time with the agent's time, those error reports generated due to a not-in-time-window error condition are authenticated (i.e., qoS is Auth/noPriv).
Upon receiving a report PDU a management entity may perform any error recovery actions that are appropriate, such as performing automatic error recovery (i.e.: clock synchronization) or notifying the management station operator of the error condition.
The report flag in the qoS may only be set if the message contains a get, get-next, get-bulk, or set operation. The report flag should never be set for a message that contains a response, inform, trap, or report operation. Furthermore, a report PDU is never sent by an SNMPv2 entity acting in a manager role.
In comparison, the party model did not append the 128-bit key to the message before the digest was computed. This usage of MD5 is called Keyed-MD5, and, according to security experts, it cryptographically strengthens the algorithm. Furthermore, a user's keys are localized for each agent. This gives superior security properties, as outlined in the next article.
When an agent generates a message, its current values of agentBoots and agentTime are always included in the message. When an authentic message is received by the manager, the agentBoots and agentTime values in the message are checked to ensure that they are within an acceptable time window of the manager's local values for the agent's time.
Any message that is not within the acceptable time window is discarded, possibly causing a report PDU message to be generated.
The agentID value is used to protect against attacks in which a message from a manager is replayed to different agent and/or messages from one agent are replayed as if from a different agent. Since agentID is unique within an administrative domain and the agentID is included in the portion of a message that is authenticated, the same message from/to different agents will contain a different MD5 digest, even if the same authPrivateKey is used. This prevents messages from being cross-played.
To protect against replay, authentic messages are checked to ensure that they are timely. A management entity will accept a received message as timely:
An agent entity will accept a message as timely if the message contains a value of agentBoots equal to the agent's current value of agentBoots and the message contains a value of agentTime that is within 150 seconds of the agent's current agentTime. The agent checks that the received time is strictly within the 150 second window to protect against a manager irresponsibly using an indication of time that is at some arbitrary point in the future, thus allowing captured messages to be replayed until they are no longer timely.
In order for the mechanisms described here to reliably protect against reply attacks, the indication of time at an agent must be ever increasing once the agent is installed and running. Through the use of agentBoots, a non-volatile clock which ticks at all times (even when the agent is powered down) is not required at the agent. The agentBoots value is simply incremented when the agent re-initializes and the agent's indication of time has then advanced, thus providing protection against replay attacks.
Both agentID and agentBoots must be stored in non-volatile storage. If the agent cannot determine the values of agentID or agentBoots then the value of agentBoots should be set to its maximal value (4294967295).
When an agent is first installed, it sets its local values of agentBoots and agentTime to zero. If agentTime ever reaches its maximum value (2147483647) then agentBoots is incremented, as if the agent had rebooted, and agentTime is reset to zero and starts incrementing again. If agentBoots reaches it maximum value (4294967295) manual intervention is required and the agent must be physically visited and re-configured, either with a new agentID value, or with new secret values for all users known to that agent. Note that it would take 136 years of the agent rebooting once a second for this condition to ever arise!
In order for a manager to become synchronized with an agent, the manager should set its local values of the agent's clocks (agentBoots, agentTime, and latestReceivedAgentTime) to zero. A subsequent authenticated message sent to the agent will cause an authentic error report to be returned to the manager. The error report, indicating that the manager sent a message that was not in the agent's time window, contains authentic values of the agent's clocks that may be used to update the manager's local notion of the agent's clocks. The manager may then continue with timely authentic communications, and, in particular, may re-send the authentic message that caused time synchronization to occur.
The manager and agent each have a clock that advance independently. For a manager to remain synchronized with the agent, its notion of the agent's time must remain current. If the manager's clock does not advance at the same rate as the agent's clock, then over time the manager's notion of the agent's time could vary enough that time synchronization will be lost. To prevent this condition, the manager's notion of the agent's time is updated (i.e., synchronized) whenever a message is received that is authentic, timely, and more recent than any other message received from that agent. Thus, a manager that maintains communication with an agent should never lose time synchronization with that agent.
The concept here builds upon the fact that every (network) component should have an agent which holds its management instrumentation, and this is just as true for management applications as for any other network component. Such management instrumentation is, of course, accessible through an agent. Thus, every application should have an agent which holds its management instrumentation, and therefore every application has an associated agent with a MIB view which is used for the purpose of that application sending an inform.
With this definition, some may ask why not consider an inform as an ``acknowledged trap''. The answer is related to two of the age-old SGMP/SNMP philosophies:
The USEC model requires that an application that wishes to authenticate received informs must synchronize its time with the sending application's associated agent. (This requirement is the same as is required to authenticate received traps.)
As of this writing there are four independently-developed and interoperable implementations of the USEC model, two commercial and two openly-available. Given the straight-forward design of USEC, we anticipate other implementations to be available in 2Q96.
The core of the USEC model is quite stable; however, in early 1996 we will begin development of a remote configuration MIB module for USEC. Rather than using the design team approach enjoyed by the USEC model, an open mailing list is now established for this purpose.
In the context of SNMP's User-based Security Model, the approach described is exploited by using localized keys.
The whole idea stems from the observation that, on one hand, it is highly desirable to minimize the number of keys or passwords in use when humans are involved; while on the other hand, it is very desirable for every machine to have its own key, which it shares with as few correspondents as possible.
A reasonable compromise seems to be to allow a user to have one key, and localize it for every machine he wants to access, via a cryptographically-strong one-way function.
Such compromise is most needed in SNMP's User-based Security Model, where a few network management stations talk to a great many agents, often on behalf of human users. Thus, SNMP will be used as an example during description of this approach, although the approach is not limited to SNMP.
A second consideration is to avoid direct key negotiation, and instead initialize cryptographic secrets via an off-line process. Key management subsequently occurs based on actions taken by the superior entities. For example, in the case of SNMP, cryptograhic secrets for agents are generated when an entity is initially configured, and management stations subsequently orchestrate key updates.
Finally, consider an environment in which the superior entities are relatively few and relatively secure. Preferably, these entities only need to retain key information when they are active (i.e., performing management tasks on behalf of an operator or administrator). However, this is not a requirement.
Regardless, considering the possible insecurity of Agent installations and their possibly vast number, it is desirable to ensure that if one (or more) agents are compromised, then communications between the NMS and other agents aren't also compromised. Clearly, if each agent had its own key, it would solve the problem, but the price is too high to have each NMS carrying all the keys for all the Agents that it may need to talk to. While it wouldn't be unreasonable to require this from a computer, such burden is too heavy for human operators. On the other hand, if each operator had just one key which is stored on every agent for which access is authorized, then when one agent falls, the whole network security is compromised.
So to achieve both security and convenience, it would be ideal for an operator to have a single key, and every agent to have its own unique key that is somehow derived from that operator's key.
An obvious way to achieve such compromise is to apply a one-way function to the user's key. Such a one-way function needs to be both unique to each agent, and be straightforward and simple at the same time, so a NMS has no problem constructing it as necessary.
Let's say we have a user A with key Ka, and an agent S with an identifier Is. Then a localized key Ka,s for this user and agent combination can be derived via Ka,s = Fs(Ka), where Fs(x) is a well-known one-way function unique for agent S.
Let us define Fs(x) = F(x,Is), where F(x,y) is based on any well-known cryptographically secure hash-function, such as MD5 (RFC 1321) or SHS. If we choose MD5, as it is already used in SNMP, then:
F(x,y) = MD5(x || y || x)
Ka,s = MD5(Ka || Is || Ka)
When a key for a user A is to be changed, the NMS gets the new key, localizes it using the above formula for every relevant agent, and sends the new keys for each agent via appropriate channels.
Of course, any user needs only know their own key, rather than having to know the key for each agent that may be communicated with. As such, we have achieved the goal of each operator having but a single key.
This article shows a convenient way to distribute and manage keys for some special network configurations, one example of which is SNMP. We showed, that our approach indeed achieves its goal to allow each subordinate entity to have its own key, which is not in any tractable relation with any other subordinate key, nor it is feasible to determine the generating key from subordinate's keys.
Envoy is a source code product we supply to other companies as a toolkit; our customers then add more code to produce their own network manager or agent. While Envoy includes a manager and agent as sample programs, it is the toolkit that is the product. This fact means that most of my effort is spent on the core engine code, and that the manager is a simple command-line program used primarily for demonstration purposes.
For this project I upgraded the core code to understand the SNMPv2u protocol as well as updating the sample agent and manager to use the core to communicate using SNMPv2u. I implemented most of the base protocol, including the authentication services and report features, but did not implement either the privacy or proxy services. I deferred implementing the proxy service due to time constraints. The privacy service is a bigger problem, as it uses the DES encryption algorithm which makes it difficult to export (from the US) in source form. (Unfortunately there probably isn't an appropriately strong algorithm that is exportable.)
The packet constructor routine needs to validate some new arguments such as the user-name and the quality-of-service option. It then gathers other information such as the user's authentication key and inserts all of this into the packet structure under construction.
The encode routine now needs to determine if the authentication routine needs to be invoked, and, if so, to insert the digest into the packet properly.
The decode routine required more work than the other two routines. While its basic function remains the same, the routine must now handle the authentication step (including timestamp manipulation) as well as processing the report pdu.
Finally, I needed to add the MD5 digest support for the encode and decode routines to use. I started with digest code from an older version of Envoy but needed to update it to allow for appending the key to the end of the packet in an efficient fashion. (Unlike earlier versions of various approaches to SNMP security, SNMPv2u uses Keyed-MD5.)
The databases that are needed are for users, contexts, agents and access rights. For a simple agent these can be small and simple (or even non-existent) while a manager will require larger and more complicated tables. For the current project, I choose to use the same relatively simple routines for both my manager and agent sides. In a production environment I would likely use two different schemes.
Another issue that surfaced during the discussions about the orignal SNMPv2 was the difficulty in changing objects associated with one of the parties being used to authenticate a packet. SNMPv2u neatly sidesteps this issue by mandating that an agent cache the necessary values during the decode step. This simplifies both the manager and the agent.
Under SNMPv2u, key generation procedures are slightly more involved, but are still straightforward to implement. (Unlike earlier versions of various approaches to SNMP security, SNMPv2u uses localized keys.) I imagine that many agents will pre-compute localized keys and save them, while managers may attempt to save space by maintaining a user with a single key and computing a localized key on the fly either per packet or, more likely, per ``management session''.
I believe that any successful authentication and security protocol will need to allow simple agents to avoid most of the complexity of the database code. The protocol should also require minimal resources from such simple agents.
Although I found that implementing SNMPv2u was easier than implementing the original SNMPv2, I don't think that the original SNMPv2 died due to implementation difficulty. Rather, I feel it died because one had to deploy all the required party information. SNMPv2u is simpler in this respect, requiring less authentication and security information to be deployed. I believe this will be another requirement for any successful authentication and security protocol.
The controversy in the working group was concerned with selecting replacement technology for the administrative and security framework, and as a result, the working group could not reach agreement between several competing proposals. As a last-minute compromise, the working group agreed to a fallback position of using SNMPv1's administrative framework to replace the unworkable portions so as to allow the ``good technology'' to progress on the standardization track.
This combination of using the SNMPv1 administrative framework with the remainder of SNMPv2 is called Community-based SNMPv2 or SNMPv2c. At the last IETF meeting in Dallas, the IESG approved the progression of all but the Introduction document to Draft Standard status, with the Introduction being declared an experimental (sic) protocol. All of these approved documents are now published as RFCs (see the Standards Summary).
This and succeeding articles of this column will examine the changes to SNMPv2 as represented by those approved documents. In this article, we look at the SNMPv2c administrative framework as well as the changes to the SNMPv2 protocol and transport mappings. Future articles will examine the changes to the rules for defining MIBs (the SMI, Textual Conventions, and Conformance documents), to the SNMPv2 MIB, and to the co-existence between SNMPv1 and SNMPv2.
The primary problem with the original SNMPv2 administrative framework was the use of SNMPv2 parties. RFC 1445 specified that an SNMPv2 message was sent from one party to another party, thereby allowing the security to be based on which parties were communicating. The source and destination parties were identified in the SNMPv2 message wrapper. Inside the wrapper was the SNMPv2 PDU specifying the operation (get, get-next, get-bulk, set and so on) to be performed. The SNMPv2c compromise solution is possible because SNMPv1 also has a message wrapper which contains a version number, a community string, and an (SNMPv1) PDU.
Thus, not only does RFC 1445, the administrative framework become obsolete, but so do: RFC 1446, the security specification, which relied heavily on the definition of parties; RFC 1447, the Party MIB, which allowed configuration of parties; and, RFC 1451, the Manager-to-Manager MIB, which also relied on the definition of parties. All of these RFCs are being declared as having historic status. It is expected that some IETF working group will produce a replacement for the the Manager-to-Manager MIB at some future date.
In the next issue of The Simple Times, we'll look at changes to SNMP's language for describing managed objects.
Here are two questions from the SNMP list that pointed out some fine thinking, and show that there is sometimes more behind a specification than meets the eye.
In section 5.4.3.3, ``Mapping of the MIN-ACCESS clause'', it indicates that the MIN-ACCESS clause may not be used in a MODULE-COMPLIANCE macro for objects where the level of access is ``fixed according to their syntax definition''. The example given is an object with the syntax of the textual convention of RowStatus.
Now, I have defined a conceptual table within my MIB that is mandatory and it includes a RowStatus columnar object. The intention of the table is to allow managers to add/delete rows, but I fully expect some agent implementations to provide a limited version of this table that does not allow addition/deletion. I expected that the MODULE-COMPLIANCE macro would allow this, but it appears that it doesn't.
Is this really the intention, or am I missing something?
But, note that RFC 1573, RFC 1604, RFC 1698, and RFC 1747 all define RowStatus objects for which they have conformance statements with a MIN-ACCESS.
Bottom-line: I think RowStatus needs to be deleted as an example in Section 5.4.3.3.
``Otherwise, if the variable binding's value field contains an ASN.1 encoding which is inconsistent with that field's ASN.1 tag, then the value of the Response-PDU's error-status field is set to `wrongEncoding', and the value of its error-index field is set to the index of the failed variable binding. (Note that not all implementation strategies will generate this error.)''
Can someone please explain the reasoning behind that parenthetical caveat? What cases is it supposed to cover...what alternative action (error-code) would one of these implementation strategies report? Or is it intended that an implementation strategy might just silently fix-up the encoding error if it can?
After 18 months of wretched inactivity, we're back in publication. You'll notice two changes: a new format and more content.
For another example, check out the unofficial index of IETF MIB modules. There you will find every MIB module developed by the IETF, in full hypertext format. Reading a MIB module and need to contact the module's editor or look up an object defined in another module? Just click.
It's a pity we didn't have Internet hypertext in the early days, because the Standards Summary really benefits from it! Speaking of which, here are three other hypertext resources of interest to the SNMP community:
Previously, only one outside technical article per issue was solicited. The new editorial policy allows each issue to have up to one technical article in each of the following areas:
Of course, each issue will still contain considerable information about SNMP:
Full Standards:
Proposed Standards:
Experimental:Full Standards:
MIB module checking:
MIB module conversion:Agents:
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via electronic mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.
Back issues are available, either via the Web or anonymous FTP.
In addition, The Simple Times has several hard copy distribution outlets. Contact your favorite SNMP vendor and see if they carry it.