draft: simple security mechanism

[Aleksey Y Romanov <[e-mail]>]

Hi,

I promised simple security mechanism draft and it is ready to be submitted.
It is partially based on ideas and contributuions form Glenn and especially
from Uri. 

It provides simple, self-synchronizing, single clock mechanism.  It is as
secure as current SNMPv2 at least. It is expressed in admin model independent
form. E.g. it can be used with SNMPv2 admin model as is is described current
drafts.

Aleksey

=========================================================================



                 Simple Authentication Mechanism for SNMP.

                      Status of this Memo


This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).



0. Acknowledgements.

We want to acknowledge SNMPv2 Working Group for their contributions that
are used in this draft, especially Uri Blumenthal and Glenn Waters.
In its essence this proposal is nothing else than combination of proposals
put forward by Uri and Glenn with the idea of clock self-synchronization.


1.  Introduction

One of the primary concerns  with SNMPv1 and SNMPv1.5  is the lack
of security. One of the primary concerns with SNMPv2 is complexity
of its administrative model,  to which  SNMPv2 security operations
are strongly tied.

It is the purpose of this memo  to define a simple authentication
protocol, that is administrative framework independent. It can be
used by various administrative frameworks being defined on top of
SNMPv2 protocol operations.

This memo is applicable to any SNMP framework, that uses SNMPv2 SMI
and operations.


2. Discussion.

The main purpose of this chapter is to answer two questions: why
yet another authentication protocol is needed and what is so
different about this one.

Actually, there already is pretty good authentication proposed,
namely SNMPv2. Unfortunately, it wasn't accepted by the community,
and if we must guess about the reasons, it's complexity will
probably be the first.

Another problem is clock synchronization. For a manager it shouldn't
be a big deal to keep state for every other entity he's talking to.
But for an agent such a requirement, at least in the eyes of some,
goes well beyond the tolerable.  There is also know weakness of existing
SNMPv2 security protocol, it relies on unprotected read of MIB variables
if clock synchronization is lost. 

There is an Internet Draft published recently by Glenn Waters. It is 
much simpler than an original SNMPv2 unfortunately it does not 
provide mechanism for on the fly clock skew adjustment and again
for resynchronization it relies on unprotected read of MIB variable.

This proposal will try to offer security which comparable or better than
SNMPv2 level, but at lower price. In addition this proposal improves
protection against response replies and provides secure mechanism for
clock resynchronization.

Another (historical) problem with all SNMP security proposals up to date
(Secure SNMP, SNMPv2, Glenn Water's one) is that all of them were tightly
coupled with particular administration model and SNMP communication 
format. These are actually two separate problems which can be resolved
independently from one another. E.g. while community has enough experience
dealing with security issues, admin model issues are far from being
solved. 

One of the goals of this proposal is to put an end to this tradition. This
proposal is intentionally expressed in communication format and admin model
neutral language. It can be easily mapped on existing SNMPv2 message format
and on some proposed extensions of SNMPv1 format for SNMPv2  operations. 

The author is that this proposal can serve as base which will allow to
put security problems behind us. And to attack a really vexing issue -
SNMP admin model.

2.1 Attacks we're defending against.

- Message modification.

- Injection of a false message (spoofing, masquerading).

- Replay of an old message.

Denial of service isn't our concern, since as Marshall Rose pointed
out in Dallas, there's no defense against this one anyway.

2.2. Defenses.

To deal with masquerading and message modification, message digest is
employed,  namely keyed digest. This guarantees that both the message
was delivered intact, and the sender possessed the secret key (thus
identifying the message source).

To prevent message replay, timestamp is used. But in order to allow
the communities to be shared,  and to relieve the agent from having
to remember the clocks for everybody else,  agent's clock is made
authoritative. Every manager must synchronize his notion of agent's
clock by the agent's real-time clock. Agent's clock isn't changeable
by a manager, thus no potential clock leapfrogging.

To prevent a replay of a response  from an agent to another manager
within message life time, a random nonce is introduced. This allows
to tie the response to the outstanding request. The only reason
request-id isn't good enough is that there's no requirement
governing it's behavior, and thus it's feasible to have all the
managers starting with request-id 1 and so on...

A replay of a request is possible within the message lifetime. For
read-type requests it's not so bad, and SNMPv2 didn't protect against
this either. But for Set it's unacceptable, and thus other means are to
be employed, namely TestAndIncrement spin-locks, associated with the variables
one attempts to modify. This will guarantee non-replayability of Set requests.

Worth to note also, that it's very easy to go from sharing to non-sharing,
i.e. if at some point a customer decides, that he requires a unique
identification for each manager and each agent, he can simply create
communities with one member only. Of course, it doesn't work the other way,
so you can't just declare a unique user information to be shared and hope
nothing will break.

To summarize: this model uses sharing of the user information via
"communities". One community" is a group of users that is authorized
to perform certain class of actions on certain MIB.

That "community" can be installed on one or more agents. There is nothing
a management station will need in advance,  so when a user approaches it,
names the community he's a member of and the agent he wants to talk to -
the management station can proceed from there. In this sense it's almost
as good as Simplified Configuration Model, but much simpler and with no
side-effect (like requirement of garbage collection to be implemented in
the agent).

Also, this proposal doesn't mention views. But since views are part of both
SNMPv1 and SNMPv2, it's natural to expect that such a "community" entry will
have some reference to read-view and write-view. This can implicitly control
whether the community in question is allowed to perform a Set operation.



3. Elements of the Model

This section contains definitions required to understand and
implement the security model defined by this memo.


3.1  Users and Communities.

A set of users (userids) is defined on the agent entity.  A
management entity that wishes to communicate with a particular agent
entity must have knowledge of the userName it wishes to communicate with
and knowledge of the applicable attributes of the userName. This
information is likely configured into the management entity.

A user name should be viewed not as a name or an ID of an individual
user, but rather of a group of users, human or otherwise,  that from
the point of access to certain information are treated as one entity.
The best analogy is Community String from SNMPv1. Thus, when we say
"user" we actually mean a group of users, that from the agent's
point of view aren't distinguishable.

A user name and its attributes are defined as follows:

<userName>
     Data representing the name of the user. Normally it will be
     an OCTET STRING. but could be OBJECT IDENTIFIER or something
     else.

<authProtocol>
     Authentication algorithm associated with this userName.

<authPrivateKey>
     Private key used for authentication of communications
     with this userName. Normally is 16 bytes long, but can
     have variable length.

<lifetimeWindow>
     An integer value that specifies the amount of seconds that
     messages signed by this userName are valid.

<authClock>
     Authentication clock used by particular user. All users located
     at particular SNMP entity will share same authClock. A manager
     will keep not only the notion of agent's clock, but the last
     received authenticated timestamp as well (if no authenticated
     communications had been received yet this value is 0).

Note, that <authClock> isn't kept on the entity in Agent role,  and
it's function is performed by real-time clock of the box Agent runs
on.

3.2  TImestamp and Nonce.

The only authoritative clock is the clock that runs on the agent.
It is read-only, it's never adjusted and the only assumption that
is made about it, is that it's increasing monotonically.

A managing entity keeps notion of the clock for every managed
entity it talks to.

When a managing entity issues a request, it uses it's notion of
the agent's clock in the timestamp. When a managed entity sends
a response, it uses it's current real-time clock value.

A Nonce is a random value, that accompanies a timestamp. Nonces
are generated by a managing entity, on per-request basis, and
are copied to the corresponding field in the response. They are
used to prevent a replay within the lifetimeWindow, and to prevent
replaying a response addressed to one manager, to another.

Nonces can be cryptographically strong. A simple and reliable
method of generating good nonce will be given in the appendix.
Due to fact that nonce values are not analyzed by agent, but
just are copied back to response communication it is matter of
choice for NMS implementors to pick up appropriate strength
of nonce protection. It can be not used at all it can be as weak
as fixed number assigned to NMS by local authority or as weak as
slowly changing random number or as strong as well generated per
packet random number.

Note: that this freedom of choice does not hurt interoperability
two NMS with different choice of nonce generation can share same
userID on the same SNMP-Agent entity.


3.3.  Mechanisms

To realize the goals of security, the following mechanisms are employed:

- To support message origin authentication and message integrity, a
  message digest algorithm is used. To be compliant with this
  memo, the message digest function must be implemented.

- To protect against message delay or replay, a timestamp and a nonce
  is included in each message. The receiver of a message by looking at
  the timestamp must determine if the message is timely, and by the
  nonce - whether it's a response to it's request or not.


3.4  Message Digest Algorithm

While particular algorithm for message digest calculation can be chosen
from the wide variety of algorithms, it is assumed that MD5 will be
most widely used one.  For any operation that specifies MD5 for its
digest algorithm the length of the digest is 16 octets.

A password is used as the basis for the MD5 authentication key. Since a
password is human generated and may be less than the 16 octets required
by the MD5 algorithm, the password is mapped to a MD5 authentication key
by forming a string of length 1,048,576 octets by repeating the value of
the password as often as necessary, truncating accordingly, and using
the resulting string as the input to the MD5 algorithm. It is appended
by the Agent ID in order for the "real" authentication key to be
location-specific, in other words to prevent a malicious person from
accessing every node with this userName, if he obtained the keys from
one agent.  The resulting digest is the authentication key <authPrivateKey>
for the userName.


3.5. Elements of the Format

It is assumed that each packet sent and delivered has to contain the
following fields. Their order, encoding, size and values of each field,
along with what other fields are present in packet are defined by
particular application of this authentication protocol.

<userName>

<authClock>

<nonce>

<authDigest>

<PDU>



4.  Elements of the Procedures

4.1.  Generating a Request (except InformRequest)

This section describes the procedure followed by a SNMP entity when
generating a management request.

(1)  The <userName>, <authClock>, <authProtocol>,  <authPrivateKey>
     <nonce> and <PDU> are used to build management communication.
     <userName> identifies intended destination of the request.
     <authClock> is message generator's notion of destination's
     authCclock value. <nonce> is generated and will be kept as
     a "ticket" the response will have to present as a proof of
     it's authencity.

(2)  The SNMP message is serialized according to the rules appropriate
     for particular usage of this protocol, Initial value of <authDigest>
     is set to binary zeroes.

(3)  An authentication digest is computed over the entire serialized
     message with <authPrivateKey> both prepended and appended,
     according to the <authProtocol> specified for the <userName>.

(4)  The <authDigest> component in the serialized message is set
     to the computed authentication digest value.

(5)  Further processing of serialized message is out of scope of
     this memo. It has to include packet delivery and it may
     include encryption of serialized authenticated message.



4.2 Generating a Trap or Inform request

The procedure for generating a trap or InformRequest is identical to
generating a request with the following clarifications:

(1)  The userName used in the case userName associated with trap generator.

(2)  The authClock used is the value of the local authClock



4.3.  Processing a Received Request

(1)  Initial Message receiving operation are performed, they
     may include decrypting of message contents.  As a result of
     the operation size and location of required fields is
     determinated:
        <userName> <authClock>  <nonce> <authDigest> <PDU>.
     These operations are out of scope of this memo.

(2)  If the userName is not recognized then the appropriate
     counter is incremented and standard authentication failure
     procedures are performed.

(3)  if PDU type is incompatible with the role of SNMP entity received
     this request packet is dropped and appropriate counter value
     is incremented.

(4)  The <authDigest> is saved for future reference.  Zeroes replace
     the authDigest value in the received message and then an
     authentication digest is computed over the entire message
     with <authPrivateKey> from corresponding <userName> entry
     prepended and appended to the message, i.e.
       <key> || <message> || <key>

(5)  The saved <authDigest> is compared to the newly computed digest.
     If they are not the same the message is deemed unauthentic, the
     appropriate counter is incremented and standard authentication
     failure procedures are performed.

(6)  If authClock is not within the entity's notion of
     authClock plus or minus the lifetimeWindow for this userName
     then the appropriate counter is incremented and standard procedure
     generating response with error-status 'authorizationError' and
     error-index 0 is invoked.

     The communication is authentic if and only if the following statements
     are true:

         received-clock >= local-entity's-clock - lifetimeWindow
         received-clock <= local-entity's-clock + lifetimeWindow

(7)  The value of the <nonce> is saved to be used in the generated reply.

(8)  The message is authentic.  Regular processing of the received SNMP
     communication proceeds as described in [2].


4.4. Processing received Trap

(1)  Initial Message receiving operation are performed, they
     may include decrypting of message contents.  As a result of
     the operation size and location of required fields is
     determinated: <userName> <authClock> <nonce> <authDigest> <PDU>.
     These operations are out of scope of this memo.

(2)  If the userName is not recognized then the appropriate
     counter is incremented and standard authentication failure
     procedures are performed.

(3)  if PDU type is not SNMPv2-TrapPDU or is incompatible with the
     role of SNMP entity received this request packet is dropped
     and appropriate counter value is incremented.

(4)  If authClock is not within the entity's notion of
     sender authClock plus or minus the lifetimeWindow for this userName
     then the appropriate counter is incremented and packet is dropped.

(5)  The authDigest is saved for future
     reference.  The authPrivateKey for the userName is used to replace
     the authDigest value in the received message and then a
     authentication digest is computed over the entire message.

(6)  The saved authDigest is compared to the newly computed authDigest.
     If they are not the same the message is deemed unauthentic and the
     appropriate counter is incremented and standard authentication failure

(7)  The message is authentic.  Regular processing of the received SNMP
     communication proceeds as described in [2].



4.5.  Processing a Received Inform-Request

(1)  Initial Message receiving operation are performed, they
     may include decrypting of message contents.  As a result of
     the operation size and location of required fields is
     determinated: <userName> <authClock> <nonce> <authDigest> <PDU>.
     These operations are out of scope of this memo.

(2)  If the userName is not recognized then the appropriate
     counter is incremented and standard authentication failure
     procedures are performed.

(3)  if PDU type is not InformRequestPDU or is incompatible with the role
     of SNMP entity received this request packet is dropped and appropriate          counter value is incremented.

(4)  If authClock is not within the entity's notion of
     sender authClock plus or minus the lifetimeWindow for this userName
     then the appropriate counter is incremented and packet is dropped.

(5)  The authDigest is saved for future
     reference.  The authPrivateKey for the userName is used to replace
     the authDigest value in the received message and then a
     authentication digest is computed over the entire message.

(6)  The saved authDigest is compared to the newly computed authDigest.
     If they are not the same the message is deemed unauthentic and the
     appropriate counter is incremented and standard authentication failure
     procedures are performed.

(7)  The message is authentic.  Regular processing of the received SNMP
     communication proceeds as described in [2].



4.6.  Generating a Response (except response to InformRequest)

The procedure for generating a response is identical to generating a
request with the following clarifications:

(1)  The <userName> used in the response is the same <userName> that
     was specified in the request.

(2)  The <nonce> value is copied from the request.

(3)  The <authClock> is the current value of the local agent's
     real-time clock.


4.7.  Generating a Response to InformRequest

The procedure for generating a response is identical to generating a
request with the following clarifications:

(1)  The <userName> used in the response is the same <userName> that
     was specified in the request.

(2)  The <nonce> is the same as was specified in the request.

(3)  The <authClock> used is the value of <authClock> in the request.



4.8.  Processing a Received Response

(1)  Initial Message receiving operation are performed, they
     may include decrypting of message contents.  As a result of
     the operation sizes, locations and values of required fields is
     determinated: <userName> <authClock> <nonce> <authDigest> <PDU>.
     These operations are out of scope of this memo.

(2)  If the <userName> is not recognized then the appropriate
     counter is incremented and standard authentication failure
     procedures are performed.

(3)  if PDU type is incompatible with the role of SNMP entity received
     this request packet is dropped and appropriate counter value
     is incremented.

(4)  If <nonce> value differs from the one sent with the initial request,
     the message is deemed not authentic, proper counter is incremented
     and standard authentication failure procedure is executed.

(5)  The <authDigest> is saved for future reference,  and is replaced
     in the message body by zeroes. Authentication digest is computed
     over the entire message with <authPrivateKey> from the appropriate
     user entry identified by <userName>  prepended and appended to the
     entire message.

(6)  The saved <authDigest> is compared to the newly computed digest.
     If they are not the same the message is deemed unauthentic and the
     appropriate counter is incremented and standard authentication failure
     procedures are performed.

(7)  If <authClock> delivered in the packet is more than lifetime
     behind local notion of user's authClock packet is dropped

(8)  If received response is not a response to Inform-Request packet, and
     if <authClock> delivered in the packet is greater than the last received
     authenticated timestamp, local notion of user's authClock is updated with
     the <authClock> delivered in the packet, and <authClock> delivered
     in the packet becomes new value of last received authenticated timestamp.

(9)  The message is authentic.  Regular processing of the received SNMP
     communication proceeds as described in [2].



5. Clock Self Synchronization

Manager can synchronize its notion of agent clocks by issuing empty SNMP
authenticated request timestamped with latest received authenticated timstamp.
It will receive back properly timestamped and authenticated response with
`authorizationError'. This message will be accepted as authentic and manager
will use the timestamp in the `authorizationError' response to update
its notion of agent's Clock in accordance with 4.8 above.

Manger will also resynchronize its notion of agent's clock with every valid
response received, in accordance with 4.8 above.


6. Overshot packet replay protection.

Buggy manager can send packet timestamped too far ahead of agent's clock
(overshoot). It will be rejected but it can be replaid later.  Probability
of this event is low due to the self-synchronization feature built into this
protocol. However, it represents a security hole.  The window available for
replay attack is 2*lifetime in all cases.  So, it is of no concern for all
kinds of GET operations.

There are two ways to protect agent from overshot SET requests:

       1. Use uniqueness of TestAndIncrement objects
          as a security measure against replays.

       2. Make NMS to change secret after every overshot
          and/or on the regular basis.

          Overshot packet is not available for replay
          immediately. So, there is a plenty of time do
          password change.

It seems that option (1) will provide for enough security for major
uses. Option (2) can be used by people with greater security concerns.


7. Appendix -  How to generate good nonce.

The best way is to use a real random-number generator,  the next best
is cryptographically strong pseudo-random number generator (PRNG). An
engine for PRNG can be either DES on OFB mode, or MD5. There is no
requirement

We recommend to prime PRNG with both Agent ID (network address can be
used) and current data and time. For real strength, one or more of
<authPrivateKey> values can be used to make the output not only
unique, but also truly unpredictable.

If MD5 is used, only first 64 bits of the 128-bit long output should
be used.



8. Author's Address

    Aleksey Romanov
    PFA, Inc.
    P.O.Box 2067
    Westford, MA 01886

    Email:  [e-mail]



9. References.

[1]  Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).

[2]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure
     of Management Information for Version 2 of the Simple Network
     Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
     Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon
     University, May 1995.

[3]  Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
     "Administrative Infrastructure for Version 2 of the Simple Network
     Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
     Trusted Information Systems, Cisco Systems, Dover Beach Consulting,
     Inc., Carnegie Mellon University, May 1995.

[4]  Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
     "Security Protocols for Version 2 of the Simple Network Management
     Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted
     Information Systems, Cisco Systems, Dover Beach Consulting, Inc.,

[5]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
     Operations for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
     Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995.

[6]  Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
     "Party MIB for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", Internet Draft, May 1995.
     SNMP Research, Inc., Trusted Information Systems, Cisco Systems,
     Dover Beach Consulting, Inc., Carnegie Mellon University,

[7]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
     Operations for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
     Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995.  |

[8]  Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
     Systems International, MIT Laboratory for Computer Science, May
     1990.