draft Simplified Configuration Model March 1995
The Simplified Configuration Model for SNMPv2
19 March 1995 |
draft-ietf-snmpv2-scm-ds-00.txt |
Steven Waldbusser
Carnegie Mellon University
waldbusser@cmu.edu
Jeffrey D. Case
SNMP Research, Inc.
case@snmp.com
Keith McCloghrie
Cisco Systems, Inc.
kzm@cisco.com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
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".
Expires September 1995 [Page 1]
draft Simplified Configuration Model March 1995
1. Introduction
A network management system contains: several (potentially many) nodes,
each with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations. Operations of the protocol are carried
out under an administrative framework which defines both authentication
and authorization policies.
Network management stations execute management applications which
monitor and control network elements. Network elements are devices such
as hosts, routers, terminal servers, etc., which are monitored and
controlled through access to their management information.
The Administrative Infrastructure for SNMPv2 [1] defines how the
administrative framework is applied to realize effective network
management in a variety of configurations and environments. It is the
purpose of this document, the Simplified Configuration Model for SNMPv2,
to define one such deployment strategy using the administrative
framework.
1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1). The current framework is
termed the SNMP version 2 framework (SNMPv2).
2. Overview
The model describe here is based on the notion of creating transient
"management sessions" for use by a management application. Each session
is initialized by consulting a user profile, which has been previously
configured at the agent. The profile specifies such information as
authentication and authorization information, along with a maximum time
that a session may be inactive before the agent destroys it.
When a session is created, the SNMPv2 parties and corresponding access
control information are dynamically created. These parties are used to
perform protocol operations. If the management application completes
before the management session expires, it may explicitly destroy the
session. Regardless, when a session is destroyed, the corresponding
Expires September 1995 [Page 2]
draft Simplified Configuration Model March 1995
resources (e.g., parties and ACLs), are deleted by the agent.
Pictorially:
management
station agent
---------- -----
user "logs in"
request to establish a
---------------------------------------->
session for the user
agent consults
profile for user
and creates session
<----------------------------------------
identity of session
...
user requests operations
SNMP requests
---------------------------------------->
agent performs
operations
<----------------------------------------
SNMP responses
...
user "logs out"
request to destroy the
---------------------------------------->
user's session
agent deletes
session
<----------------------------------------
confirmation
Expires September 1995 [Page 3]
draft Simplified Configuration Model March 1995
3. User-based Maintenance Functions
Maintenance functions are defined in [1] as a special means for
providing controlled access to an SNMPv2 engine in order to perform
operations which are not easily accomplished using the administrative
infrastructure. The Simplified Configuration Model defines a class of
maintenance functions termed "user-based maintenance functions". As
with all maintenance functions, the "parties" and "contexts" employed
are not accessible to entities which make use of an SNMPv2 engine, nor
are they visible through the SNMPv2-PARTY-MIB [2]. These artifacts of
SNMPv2's administrative maintenance facility are not actual parties or
contexts.
A user-based maintenance function is identified when the context of a
management communication has the value userMaintContext, and the source
and destination parties identically have the form
userMaintParty.<userID>, where <userID> corresponds to an active entry |
in the |
scmUserTable, i.e.,
dstParty userMaintParty.<userID>
srcParty userMaintParty.<userID>
context userMaintContext
Each valid userMaintParty has these characteristics:
party value
----- -----
AuthProtocol scmUserAuthProtocol
AuthClock '7fffffff'H
AuthPrivate password_to_key(scmUserAuthProtocol,scmUserPassword)
AuthPublic ''H
PrivProtocol noPriv
To determine the algorithm that maps scmUserPassword to an
authentication key, consult the definition of scmUserAuthProtocol in
Section 6. Note that since the clock value for these parties is at the
maximum, no replay protection is afforded when a user-based maintenance
function is performed. Further note that these parties are configured
indirectly, by manipulating the scmUserTable -- it is not possible to
specify the instances corresponding to a userMaintParty in an SNMP
operation.
The access allowed to any pairing of userMaintParty.<userID> and
userMaintContext is statically defined to be read/write access to all
Expires September 1995 [Page 4]
draft Simplified Configuration Model March 1995
instances in one (and only one) subtree, userMaintActions.
Expires September 1995 [Page 5]
draft Simplified Configuration Model March 1995
4. Session Creation Algorithm
Sessions are created when the management station issues a user-based
maintenance function, which identifies a user configured at the agent.
Pictorially:
management
station agent
---------- -----
user supplies
identity and
password
user-based maintenance function
---------------------------------------->
parameters: transport domain and addresses
manager's maximum message size
manager desires traps
manager's desired inactivity
time for session
agent creates parties
and ACLs which realize
user's capabilities,
secrets for parties are
calculated using user's
password and a one-time
value
user-based maintenance function
<----------------------------------------
parameters: result indicator
identity of session (parties)
agent's maximum message size
actual inactivity time for
session
one-time values for secrets
manager mirrors
parties/ACLs
created by agent
Expires September 1995 [Page 6]
draft Simplified Configuration Model March 1995
4.1. Step 1: Manager Requests Creation
-
The manager performs a user-based maintenance function consisting of a |
getRequest operation containing a variable-binding supplying the |
parameters of the session to be created. An agent is not required to |
support such a getRequest hvaing more than one variable-binding. The |
variable-binding is: |
userMaintCreate.<tDomain>.<mAddr>.<aAddr>.<mMMS>.<mTraps>.<mLinger> |
where:
<tDomain>
identifies the transport domain to be used for the created parties,
encoded as a single sub-identifier, specifically the value of the
last sub-identifier of a transport domain defined under snmpDomains
[3]:
value meaning
----- --------
1 snmpUDPDomain
2 snmpCLNSDomain
3 snmpCONSDomain
4 snmpDDPDomain
5 snmpIPXDomain
<mAddr> |
identifies the transport address to be used when the agent sends
traps to the manager, encoded as 1+N sub-identifiers, where the
first sub-identifier indicates the length of the address, and the
remaining sub-identifiers correspond to one octet from that address
([3] defines the address format corresponding to each transport
domain). If the manager doesn't desire traps, then this field is
encoded as a single sub-identifier having the value zero.
<aAddr> |
identifies the transport address that the agent listens to when the
manager sends traffic, encoded as 1+N sub-identifiers, where the
first sub-identifier indicates the length of the address, and the
remaining sub-identifiers correspond to one octet from that address
([3] defines the address format corresponding to each transport
domain).
<mMMS> |
identifies the maximum message size which the manager can receive,
Expires September 1995 [Page 7]
draft Simplified Configuration Model March 1995
encoded as 1 sub-identifier in the range 484 to 65507.
<mTraps> |
identifies whether the manager wishes to receive traps from the
agent, encoded as a single sub-identifier:
value meaning
----- --------
0 no traps
1 send traps using without authentication or privacy
2 send traps using authentication
3 send traps using authentication and privacy
<mLinger> |
identifies the manager's desire for minimum number of contiguous
seconds of inactivity for all parties and access control entries
created before they are destroyed by the agent, encoded as 1 sub-
identifier in the range 1 to 2147483647.
4.2. Step 2: Agent Analyzes Request
The agent receives the get request from the manager and identifies it as
a user-based maintenance function to create a session.
The agent examines the parameter encoded in the instance-identifier of
the one (and only) variable-binding of the get operation, and if any are
unacceptable, it generates a response to the get operation, containing a
single octet value:
value meaning
----- --------
1 bad tDomain value
2 bad mAddr value |
3 bad aAddr value |
4 bad mMMS value |
5 bad mTraps value |
6 bad mLinger value |
Expires September 1995 [Page 8]
draft Simplified Configuration Model March 1995
Otherwise, the agent retrieves the following information:
(1) the entry in the scmUserTable which corresponds to the user
identified in the management communication;
(2) its 12-octet administratively-unique identifier, agentID [2]; |
and,
(3) the maximum message size which the agent can receive, aMMS. |
The agent calculates actualLinger by taking the minimum of mLinger and |
the corresponding instance of scmUserLinger. If the value of
actualLinger is 2147483647, then the agent sets creationType to
nonVolatile, otherwise creationType is set to volatile.
The agent computes an integer, sessionID, such that there are no parties
known to the agent whose name is any of:
scmAgentNoAuthPartyID.<agentID>.<sessionID>
scmManagerNoAuthPartyID.<agentID>.<sessionID>
scmAgentAuthPartyID.<agentID>.<sessionID>
scmManagerAuthPartyID.<agentID>.<sessionID>
scmAgentPrivPartyID.<agentID>.<sessionID>
scmManagerPrivPartyID.<agentID>.<sessionID>
where <agentID> identifies the agent's unique identifier, encoded as 12
sub-identifiers.
The agent generates an unpredictable 128-bit quantity, aPad. The agent
computes aSecret, based on an algorithm which uses the pairing of the
value of partyAuthPrivate for userMaintParty.<userID> and aPad --
consult the definition of scmUserAuthProtocol in Section 6.
If the value of scmUserPrivProtocol is any value other than noPriv, the
agent generates a second unpredictable 128-bit quantity, pPad, and the
agent computes pSecret, based on an algorithm which uses the pairing of
the value of partyAuthPrivate for userMaintParty.<userID> and pPad --
consult the definition of scmUserAuthProtocol in Section 6.
Expires September 1995 [Page 9]
draft Simplified Configuration Model March 1995
4.3. Step 3: Agent Creates Parties
The agent creates four parties named as:
scmAgentNoAuthPartyID.<agentID>.<sessionID>
scmManagerNoAuthPartyID.<agentID>.<sessionID>
scmAgentAuthPartyID.<agentID>.<sessionID>
scmManagerAuthPartyID.<agentID>.<sessionID>
where:
<agentID>
identifies the agent's agentID [2], |
encoded as 12 sub-identifiers.
<sessionID>
identifies this session's sessionID, encoded as 1 sub-identifier.
The parties are created with these values:
Agent Manager Agent Manager
party noAuth noAuth Auth Auth
----- ------- ------- ------- -------
TDomain tDomain tDomain tDomain tDomain
TAddress aAddr mAddr aAddr mAddr |
MaxMessageSize aMMS mMMS aMMS mMMS |
Local true false true false
AuthProtocol noAuth noAuth scmUserAuth scmUserAuth
AuthClock 0 0 0 0
AuthPrivate ''H ''H aSecret aSecret
AuthPublic ''H ''H ''H ''H
PrivProtocol noPriv noPriv noPriv noPriv
PrivPrivate ''H ''H ''H ''H
PrivPublic ''H ''H ''H ''H
StorageType creationType creationType creationType creationType
Status active active active active
Expires September 1995 [Page 10]
draft Simplified Configuration Model March 1995
If the value of scmUserPrivProtocol is any value other than noPriv, then
the agent also creates two more parties named as:
scmAgentPrivPartyID.<agentID>.<sessionID>
scmManagerPrivPartyID.<agentID>.<sessionID>
and having these values:
Agent Manager
party Priv Priv
----- ------- -------
TDomain tDomain tDomain
TAddress aAddr mAddr |
MaxMessageSize aMMS mMMS |
Local true false
AuthProtocol scmUserAuth scmUserAuth
AuthClock 0 0
AuthPrivate aSecret aSecret
AuthPublic ''H ''H
PrivProtocol scmUserPriv scmUserPriv
PrivPrivate pSecret pSecret
PrivPublic ''H ''H
StorageType creationType creationType
Status active active
Expires September 1995 [Page 11]
draft Simplified Configuration Model March 1995
4.4. Step 4: Agent Authorizes Parties
For each entry in the scmCapTable whose value of scmCapIndex equals the
value of scmUserCapIndex for the user identified in the management
communication, the agent performs Step 4a and 4b.
4.4.1. Step 4a: Agent Checks Contexts
If the context named as:
scmContextID.<agentID>.<localTime>.<localEntity>
where:
<agentID>
identifies the agent's agentID, encoded as 12 sub-identifiers.
<localTime>
identifies the value of scmCapCtxLocalTime, encoded as 1 sub-
identifier.
<localEntity>
identifies the value of scmCapCtxLocalEntity, encoded as N
(possibly 0) sub-identifiers.
does not exist, then the agent creates it:
context value
------- -----
Local true
View 1
LocalEntity scmCapCtxLocalEntity
LocalTime scmCapCtxLocalTime
(expressed as the equivalent OBJECT IDENTIFIER)
ProxyDstParty 0.0
ProxySrcParty 0.0
ProxyContext 0.0
StorageType creationType
Status active
Expires September 1995 [Page 12]
draft Simplified Configuration Model March 1995
4.4.2. Step 4b: Agent Creates Access Control Entries
The agent creates 2 entries in the acTable:
ac value for ACL #1 value for ACL #2
----- ---------------- ----------------
Target Agent noAuth Agent Auth
Subject Manager noAuth Manager Auth
Context context from Step 4a context from Step 4a
Privileges scmCapNPrivileges scmCapAPrivileges
ReadViewIndex scmCapNReadView scmCapAReadView
WriteViewIndex scmCapNWriteView scmCapAWriteView
StorageType creationType creationType
Status active active
If the value of mTraps is 1, |
then 128 is added to the value of acPrivileges for ACL #1; otherwise, if |
the value of mTraps is 2, |
then 128 is added to the value of acPrivileges for ACL #2.
If the value of scmUserPrivProtocol is any value other than noPriv, then
the agent creates a third entry in the acTable:
ac value for ACL #3
----- ----------------
Target Agent Priv
Subject Manager Priv
Context context from Step 4a
Privileges scmCapPPrivileges
ReadViewIndex scmCapPReadView
WriteViewIndex scmCapPWriteView
StorageType creationType
Status active
If the value of mTraps is 3, |
then 128 is added to the value of acPrivileges for ACL #3.
When an agent already has many activated user sessions, it is |
undesirable for the creation of a new session to be denied due to the |
inability of the agent to create the additional parties or access |
control entries. |
As such, if an agent having many active user sessions is unable to |
perform Steps 3 or 4 due to lack of party-related resources, the agent |
should begin destroying sessions, |
in the order least recently used, until sufficient party-related
Expires September 1995 [Page 13]
draft Simplified Configuration Model March 1995
resources exist to perform Steps 3 and 4.
Expires September 1995 [Page 14]
draft Simplified Configuration Model March 1995
4.5. Step 5: Agent Responds
The agent generates a response to the get operation, an octet string
having this value:
<result>
a single octet, containing the value 0.
<agentID>
12 octets, containing the agent's 12-octet administratively-unique
identifier.
<sessionID>
4 octets, encoded as an unsigned integer using network-byte
ordering (big-endian encoding).
<agentMMS>
2 octets, encoded as an unsigned integer using network-byte
ordering (big-endian encoding).
<actualLinger>
4 octets, encoded as an unsigned integer using network-byte
ordering (big-endian encoding).
<aPad>
16 octets.
<pPad>
16 octets.
If the value of scmUserPrivProtocol is noPriv, then no pPad value is
sent (the aPad value completes the response).
4.6. Step 6: Agent Starts Initial Inactivity Timer
Upon sending the response to the get operation, the agent starts a 5 +
minute timer. If any of the session's 2 or 4 authenticated parties are +
used before the timer expires, then the timer is cancelled. Otherwise, +
if the timer expires before their use, then all 4 or 6 of the session's +
parties and their associated access control entries are immediately +
deleted. +
By use of this timeout, a created session for which the agent-generated +
response is lost, is deleted after after 5 minutes of non-use. +
Expires September 1995 [Page 15]
draft Simplified Configuration Model March 1995
4.7. Step 7: Manager Analyzes Response
+
The manager receives the response from the agent and correlates to its
earlier request. It then creates mirrors of the parties and access
control entries described in Steps 3 and 4b, except that the values of
partyLocal are inverted.
The manager should then issue an authenticated request which uses the +
created session. This usage serves to confirm that the session has been +
successfully created, and to cancel the agent's initial inactivity (5- +
minute) timer. +
Expires September 1995 [Page 16]
draft Simplified Configuration Model March 1995
5. Session Destruction Algorithm
Sessions are destroyed when the management station issues a user-based
maintenance function, which identifies a user configured at the agent.
Pictorially:
management
station agent
---------- -----
application terminates
user-based maintenance function
---------------------------------------->
parameters: identity of session
agent removes parties
and ACLs
user-based maintenance function
<----------------------------------------
parameters: result indicator
manager removes
mirrored parties/ACLs
Expires September 1995 [Page 17]
draft Simplified Configuration Model March 1995
5.1. Step 1: Manager Requests Destruction
The manager performs a user-based maintenance function consisting of a
set operation for
userMaintDestroy.0
setting it to an octet string having this value:
<agentID><sessionID>
where:
<agentID>
12 octets, containing the agent's 12-octet administratively-unique
identifier.
<sessionID>
4 octets, encoded as an unsigned integer using network-byte
ordering (big-endian encoding).
5.2. Step 2: Agent Analyzes Request and Responds
The agent receives the set request from the manager and identifies it as
a user-based maintenance function to destroy a session.
The agent locates those parties whose name is any of:
scmAgentNoAuthPartyID.<agentID>.<sessionID>
scmManagerNoAuthPartyID.<agentID>.<sessionID>
scmAgentAuthPartyID.<agentID>.<sessionID>
scmManagerAuthPartyID.<agentID>.<sessionID>
scmAgentPrivPartyID.<agentID>.<sessionID>
scmManagerPrivPartyID.<agentID>.<sessionID>
If no such parties exist, or if the partyStorageType of any such party
isn't volatile, or if the parties weren't created by the user
corresponding to this user-based management function, then the agent
generates an inconsistentValue response. Otherwise, the agent generates
a noError response to the set operation, and deletes all parties and |
associated access control entries. |
Expires September 1995 [Page 18]
draft Simplified Configuration Model March 1995
5.3. Step 3: Manager Analyzes Response
The manager receives the response from the agent and correlates to its
earlier request. It then destroys the mirrors of the parties and access
control entries that it created earlier.
Expires September 1995 [Page 19]
draft Simplified Configuration Model March 1995
6. Definitions
SNMPv2-SCM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, snmpModules
FROM SNMPv2-SMI
DisplayString, RowStatus
FROM SNMPv2-TC
AccessPrivileges, StorageType, v2md5AuthProtocol, noPriv |
FROM SNMPv2-PARTY-MIB;
scmMIB MODULE-IDENTITY
LAST-UPDATED "9503180000Z" |
ORGANIZATION "IETF SNMPv2 Working Group" |
CONTACT-INFO
" Keith McCloghrie
Postal: Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706
US
Tel: +1 408 526 5260
E-mail: kzm@cisco.com"
DESCRIPTION
"The MIB module for the Simplified Configuration Model."
::= { snmpModules 4 } |
Expires September 1995 [Page 20]
draft Simplified Configuration Model March 1995
-- administrative assignments
scmAdmin OBJECT IDENTIFIER ::= { scmMIB 1 }
-- parties under these subtrees are created dynamically by the agent
scmPartyID OBJECT IDENTIFIER ::= { scmAdmin 1 }
scmAgentNoAuthPartyID
OBJECT IDENTIFIER ::= { scmPartyID 1 }
scmManagerNoAuthPartyID
OBJECT IDENTIFIER ::= { scmPartyID 2 }
scmAgentAuthPartyID
OBJECT IDENTIFIER ::= { scmPartyID 3 }
scmManagerAuthPartyID
OBJECT IDENTIFIER ::= { scmPartyID 4 }
scmAgentPrivPartyID
OBJECT IDENTIFIER ::= { scmPartyID 5 }
scmManagerPrivPartyID
OBJECT IDENTIFIER ::= { scmPartyID 6 }
-- context under this subtree might be created by the agent,
-- but normally exist
scmContextID OBJECT IDENTIFIER ::= { scmAdmin 2 }
-- these are employed by user-based maintenance functions
userMaintParty OBJECT IDENTIFIER ::= { scmAdmin 3 }
userMaintContext
OBJECT IDENTIFIER ::= { 0 1 }
Expires September 1995 [Page 21]
draft Simplified Configuration Model March 1995
-- object assignments
scmMIBObjects OBJECT IDENTIFIER ::= { scmMIB 2 }
-- user table
scmUserTable OBJECT-TYPE
SYNTAX SEQUENCE OF ScmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The user table."
::= { scmMIBObjects 1 }
scmUserEntry OBJECT-TYPE
SYNTAX ScmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the user table."
INDEX { IMPLIED scmUserID }
::= { scmUserTable 1 }
ScmUserEntry ::=
SEQUENCE {
scmUserID DisplayString,
scmUserPassword OCTET STRING,
scmUserAuthProtocol OBJECT IDENTIFIER,
scmUserPrivProtocol OBJECT IDENTIFIER,
scmUserCapIndex INTEGER,
scmUserLinger INTEGER,
scmUserStorageType StorageType,
scmUserStatus RowStatus
}
Expires September 1995 [Page 22]
draft Simplified Configuration Model March 1995
scmUserID OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..64))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The identity of the user corresponding to this conceptual
row."
::= { scmUserEntry 1 }
scmUserPassword OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (8..128))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The user's password. On retrieval, this object has the
value of 8 zero-valued octets."
::= { scmUserEntry 2 }
Expires September 1995 [Page 23]
draft Simplified Configuration Model March 1995
scmUserAuthProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The authentication protocol for this user. This object may
never take the value noAuth.
Once an instance of this object is created, its value can
not be changed.
If the value of this object is v2md5AuthProtocol, then two
algorithms are defined:
To map scmUserPassword to an authentication key for the
corresponding userMaintParty: form a string of length
1,048,576 octets by repeating the value of scmUserPassword
as often as necessary, truncating accordingly, and use the
resulting string as the input to the MD5 algorithm. The
resulting digest is the authentication key for
userMaintParty.<userID>.
To map the pairing of a user's authentication key and the
aPad quantity to the authentication key for a newly
created party: append aPad to the value of
partyAuthPrivate for userMaintParty.<userID>, and use the
resulting string as the input to the MD5 algorithm. The
resulting digest is the authentication key for the newly
created party."
DEFVAL { v2md5AuthProtocol }
::= { scmUserEntry 3 }
Expires September 1995 [Page 24]
draft Simplified Configuration Model March 1995
scmUserPrivProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The privacy protocol for this user. The value noPriv
signifies that messages received by the party are not
protected.
Once an instance of this object is created, its value can
not be changed.
If the value of this object is desPrivProtocol, then one
algorithm is defined:
To map the pairing of a user's authentication key and the
pPad quantity to the privacy key for a newly created
party: append pPad to the value of partyAuthPrivate for
userMaintParty.<userID>, and use the resulting string as
the input to the MD5 algorithm. The resulting digest is
the privacy key for the newly created party."
DEFVAL { noPriv }
::= { scmUserEntry 4 }
scmUserCapIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of an instance of this object identifies one or
more conceptual rows in the scmCapTable, and has the same
value as the instance of scmCapIndex for those conceptual
rows."
::= { scmUserEntry 5 }
Expires September 1995 [Page 25]
draft Simplified Configuration Model March 1995
scmUserLinger OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper bound on the minimum number of contiguous seconds
that a dynamically created party may reside in the agent and
neither generate nor receive management communications,
before the agent may choose to set the party's status to
`destroy(6)'."
::= { scmUserEntry 7 }
scmUserStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
scmUserTable."
::= { scmUserEntry 8 }
scmUserStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row in the scmUserTable. If
set to `destroy(6)', then any parties (and associated access
control entries) having a storage type of `volatile(2)'
which were earlier created for this user have their status
set to `destroy(6)'."
::= { scmUserEntry 9 }
Expires September 1995 [Page 26]
draft Simplified Configuration Model March 1995
-- capabilities table
scmCapNextIndex OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The next unassigned value of scmCapIndex. The value 0
indicates that no unassigned values are available.
Reading a non-zero value causes the assignment of the
retrieved value for use as the scmCapIndex of a future
capability, and thus causes the value of this object to
change. -
The algorithm for changing scmCapIndex is implementation- +
dependent, and the agent may use a subset of values within +
1..2147483647, but the agent must guarantee that the value +
held by this object is not assigned to any in-use value of +
scmCapIndex, e.g., is not pointed to by any other MIB +
object. +
A management station should create a new MIB view using this
algorithm: first, issue a management protocol retrieval
operation to obtain the value of scmCapNextIndex -- this
value is used as the scmCapIndex of the new capability; and,
second, issue a management protocol set operation to create
an instance of the scmCapStatus object setting its value to
`createAndGo' or `createAndWait' (as specified in the
description of the RowStatus textual convention)."
::= { scmMIBObjects 2 }
scmCapTable OBJECT-TYPE
SYNTAX SEQUENCE OF ScmCapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The capabilities table."
::= { scmMIBObjects 3 }
Expires September 1995 [Page 27]
draft Simplified Configuration Model March 1995
scmCapEntry OBJECT-TYPE
SYNTAX ScmCapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the capabilities table."
INDEX { scmCapIndex, scmCapCtxLocalTime,
IMPLIED scmCapCtxLocalEntity }
::= { scmCapTable 1 }
ScmCapEntry ::=
SEQUENCE {
scmCapIndex INTEGER,
scmCapCtxLocalTime INTEGER,
scmCapCtxLocalEntity OCTET STRING,
scmCapNPrivileges AccessPrivileges,
scmCapNReadView INTEGER,
scmCapNWriteView INTEGER,
scmCapAPrivileges AccessPrivileges,
scmCapAReadView INTEGER,
scmCapAWriteView INTEGER,
scmCapPPrivileges AccessPrivileges,
scmCapPReadView INTEGER,
scmCapPWriteView INTEGER,
scmCapStorageType StorageType,
scmCapStatus RowStatus
}
scmCapIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each capability. The value for each
capability must remain constant at least from one re-
initialization of the entity's network management system to
the next re-initialization."
::= { scmCapEntry 1 }
Expires September 1995 [Page 28]
draft Simplified Configuration Model March 1995
scmCapCtxLocalTime OBJECT-TYPE
SYNTAX INTEGER { currentTime(1), restartTime(2) }
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The temporal context associated with this capability."
::= { scmCapEntry 2 }
scmCapCtxLocalEntity OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local entity associated with this capability."
::= { scmCapEntry 3 }
scmCapNPrivileges OBJECT-TYPE
SYNTAX AccessPrivileges
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The access privileges which govern the flow of management
information between the user and the agent when
communicating using unauthenticated traffic."
::= { scmCapEntry 4 }
scmCapNReadView OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to a MIB view of a locally accessible entity,
when the user requests the get, get-next, or get-bulk
operations using unauthenticated traffic; the value of the
instance identifies the particular MIB view which has the
same value of viewIndex."
::= { scmCapEntry 5 }
Expires September 1995 [Page 29]
draft Simplified Configuration Model March 1995
scmCapNWriteView OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to a MIB view of a locally accessible entity,
when the user requests the set operation using
unauthenticated traffic; the value of the instance
identifies the particular MIB view which has the same value
of viewIndex."
::= { scmCapEntry 6 }
scmCapAPrivileges OBJECT-TYPE
SYNTAX AccessPrivileges
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The access privileges which govern the flow of management
information between the user and the agent when
communicating using authenticated, but not private,
traffic."
::= { scmCapEntry 7 }
scmCapAReadView OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to a MIB view of a locally accessible entity,
when the user requests the get, get-next, or get-bulk
operations using authenticated, but not private, traffic;
the value of the instance identifies the particular MIB view
which has the same value of viewIndex."
::= { scmCapEntry 8 }
Expires September 1995 [Page 30]
draft Simplified Configuration Model March 1995
scmCapAWriteView OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to a MIB view of a locally accessible entity,
when the user requests the set operation using
authenticated, but not private, traffic; the value of the
instance identifies the particular MIB view which has the
same value of viewIndex."
::= { scmCapEntry 9 }
scmCapPPrivileges OBJECT-TYPE
SYNTAX AccessPrivileges
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The access privileges which govern the flow of management
information between the user and the agent when
communicating using authenticated and private traffic."
::= { scmCapEntry 10 }
scmCapPReadView OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to a MIB view of a locally accessible entity,
when the user requests the get, get-next, or get-bulk
operations using authenticated and private traffic; the
value of the instance identifies the particular MIB view
which has the same value of viewIndex."
::= { scmCapEntry 11 }
Expires September 1995 [Page 31]
draft Simplified Configuration Model March 1995
scmCapPWriteView OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to a MIB view of a locally accessible entity,
when the user requests the set operation using authenticated
and private traffic; the value of the instance identifies
the particular MIB view which has the same value of
viewIndex."
::= { scmCapEntry 12 }
scmCapStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
scmCapTable."
::= { scmCapEntry 13 }
scmCapStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row in the scmCapTable."
::= { scmCapEntry 14 }
Expires September 1995 [Page 32]
draft Simplified Configuration Model March 1995
-- maintenance assignments
-- these objects are accessible only to user-based maintenance
-- functions
userMaintActions
OBJECT IDENTIFIER ::= { scmMIB 3 }
userMaintTable OBJECT-TYPE
SYNTAX SEQUENCE OF UserMaintEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A pseudo-table provided to allow indexing for
userMaintCreate."
::= { userMaintActions 1 }
userMaintEntry OBJECT-TYPE
SYNTAX UserMaintEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries in this table are created by the agent dynamically
when processing a getRequest operation, and are deleted |
immediately thereafter. |
As such, entries are not accessible via other retrieval
operations."
INDEX { IMPLIED userMaintIndex } |
::= { userMaintTable 1 }
UserMaintEntry ::=
SEQUENCE {
userMaintIndex OCTET STRING,
userMaintCreate OCTET STRING
}
Expires September 1995 [Page 33]
draft Simplified Configuration Model March 1995
userMaintIndex OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A pseudo-index provided to allow indexing for |
userMaintCreate. Its value is the BER-encoding of the set |
of OBJECT IDENTIFIER sub-identifiers which a manager appends |
to userMaintCreate in order to supply the parameters for the |
session creation algorithm." |
::= { userMaintEntry 1 }
userMaintCreate OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1|39|55))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A getRequest operation on this object is used to invoke the |
session creation algorithm." |
::= { userMaintEntry 2 }
userMaintDestroy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (16))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A set operation on this object is used to invoke the
session destruction algorithm. On retrieval, this object
has the value of 16 zero-valued octets."
::= { userMaintActions 2 }
Expires September 1995 [Page 34]
draft Simplified Configuration Model March 1995
-- conformance information
scmMIBConformance
OBJECT IDENTIFIER ::= { scmMIB 4 }
scmMIBCompliances
OBJECT IDENTIFIER ::= { scmMIBConformance 1 }
scmMIBGroups
OBJECT IDENTIFIER ::= { scmMIBConformance 2 }
-- compliance statements
scmMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the Simplified Configuration Model."
MODULE -- this module
MANDATORY-GROUPS { scmGroup, userMaintGroup }
::= { scmMIBCompliances 1 }
Expires September 1995 [Page 35]
draft Simplified Configuration Model March 1995
-- units of conformance
scmGroup OBJECT-GROUP
OBJECTS { scmUserPassword,
scmUserAuthProtocol, scmUserPrivProtocol,
scmUserCapIndex, scmUserLinger,
scmUserStorageType, scmUserStatus,
scmCapNextIndex,
scmCapNPrivileges, scmCapNReadView, scmCapNWriteView,
scmCapAPrivileges, scmCapAReadView, scmCapAWriteView,
scmCapPPrivileges, scmCapPReadView, scmCapPWriteView,
scmCapStorageType, scmCapStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing support for the
Simplified Configuration Model."
::= { scmMIBGroups 1 }
userMaintGroup OBJECT-GROUP
OBJECTS { userMaintCreate, userMaintDestroy }
STATUS current
DESCRIPTION
"A collection of objects providing support for user-based
maintenance functions."
::= { scmMIBGroups 2 }
END
Expires September 1995 [Page 36]
draft Simplified Configuration Model March 1995
7. Appendix A: Password to Key Algorithm
The following code fragment demonstrates the password to key algorithm |
used when mapping scmUserPassword to an authentication key for a |
userMaintParty when the |
value of scmUserAuthProtocol is v2md5AuthProtocol:
void v2md5auth_password_to_key(password, passwordlen, key) |
u_char *password; /* IN */
u_int passwordlen; /* IN */
u_char *key; /* OUT - caller supplies pointer to 16
octet buffer */ {
MDstruct MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
MDbegin(&MD); /* initialize MD5 */
/* loop until we've done 1 Megabyte */
while (count < 1048576) {
cp = password_buf;
for(i = 0; i < 64; i++){
*cp++ = password[ password_index++ % passwordlen ];
/*
* Take the next byte of the password, wrapping to the
* beginning of the password as necessary.
*/
}
MDupdate(&MD, password_buf, 64 * 8);
/*
* 1048576 is divisible by 64, so the last MDupdate will be
* aligned as well.
*/
count += 64;
}
MDupdate(&MD, password_buf, 0); /* tell MD5 we're done */
copy_digest_to_buffer(&MD, key);
return; }
Expires September 1995 [Page 37]
draft Simplified Configuration Model March 1995
8. Acknowledgements
The Simplified Configuration Model is based on the "Simplified Security
Conventions" developed by Steve Waldbusser, and subsequently updated by
the SNMPv2 Working Group.
The authors wish to acknowledge in particular the contributions of the +
following individuals +
Dave Arneson (Cabletron), +
Uri Blumenthal (IBM), +
Doug Book (Chipcom), +
Deirdre Kostik (Bellcore), +
Dave Harrington (Cabletron), +
Jeff Johnson (Cisco Systems), +
Brian O'Keefe (Hewlett Packard), +
Dave Perkins (Bay Networks), +
Randy Presuhn (Peer Networks), +
Shawn Routhier (Epilogue), +
Bob Stewart (Cisco Systems), +
Kaj Tesink (Bellcore). +
Expires September 1995 [Page 38]
draft Simplified Configuration Model March 1995
9. References
[1] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Administrative Model for version 2 of the Simple Network
Management Protocol (SNMPv2)", in progress, SNMP Research, Inc.,
Trusted Information Systems, Cisco Systems, Dover Beach Consulting,
Inc., Carnegie Mellon University, March, 1995.
[2] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Party MIB for version 2 of the Simple Network Management Protocol
(SNMPv2)", in progress, SNMP Research, Inc., Trusted Information
Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie
Mellon University, March, 1995.
[3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport
Mappings for version 2 of the Simple Network Management Protocol
(SNMPv2)", in progress, SNMP Research Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., Carnegie Mellon University, March,
1995.
Expires September 1995 [Page 39]
draft Simplified Configuration Model March 1995
10. Security Considerations
The mechanisms defined in this document allow "users" to be configured,
and to activate management sessions for them. How "users" are defined
is subject to the security policy of the network administration. For
example, users could be individuals (e.g., "joe" or "jane"), or a
particular role (e.g., "operator" or "administrator"), or a combination
(e.g., "joe-operator", "jane-operator" or "joe-admin"). Furthermore, a
"user" may be a logical entity, such as a manager station application or
set of manager station applications, acting on behalf of a individual or
role, or set of individuals, or set of roles, including combinations.
The mechanisms also allow management capabilities to be defined, where
one or more users can be authorized for a set of capabilities.
A password is defined for each user, and these passwords will often be
generated, remembered, and input by a human. Because human-generated
passwords may be less than the 16 octets required by the MD5
authentication protocols, and because brute force attacks can be quite
easy on a relatively short ASCII character set, passwords are not used
directly, but are instead mapped by the algorithm described in Section 6
and Appendix A. Agent implementations (and agent configuration
applications) must ensure that passwords are at least 8 characters in
length.
Because these passwords are used (nearly) directly, it is very important
that they not be easily guessed. It is suggested that they be composed
of mixed-case alphanumeric and punctuation characters that don't form
words or phrases that might be found in a dictionary. Longer passwords
improve the security of the system. Users may wish to input multiword
phrases to make their password string longer while ensuring that it is
memorable.
Note that there is security risk in configuring the same "user" on |
multiple systems where the same password is used on each system, since |
the compromise of that user's secrets on one system results in the |
compromise of that user on all other systems having the same password. |
There is also greater security risk and less accountability in allowing |
multiple humans to know the password for a given "user". |
Note also that the userMaintParty authentication key for a user is the |
same for all systems on which the user has the same password, and it is |
necessary to store that authentication key on each such system. As |
such, an implementation must, to the maximal extent possible, prohibit |
read-access to these authentication keys under all circumstances except |
as required to generate and/or validate SNMPv2 messages containing |
Expires September 1995 [Page 40]
draft Simplified Configuration Model March 1995
user-based maintenance functions. |
With respect to the replay-ability of user-based maintenance functions,
note that all such operations are effectively idempotent: replaying a
request to create a session results in a new session being created, but
the session has a new unique set of keys, which can be derived only by
an authorized user; similarly, replaying a request to destroy a session
results in an inconsistentValue error.
Expires September 1995 [Page 41]
draft Simplified Configuration Model March 1995
11. Authors' Address
Steven Waldbusser
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
Phone: +1 615 573 1434
Email: case@snmp.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706
Phone: +1 408 526 5260
EMail: kzm@cisco.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
Expires September 1995 [Page 42]
draft Simplified Configuration Model March 1995
Table of Contents
1 Introduction .................................................... 2
1.1 A Note on Terminology ......................................... 2
2 Overview ........................................................ 2
3 User-based Maintenance Functions ................................ 4
4 Session Creation Algorithm ...................................... 6
4.1 Step 1: Manager Requests Creation ............................. 7
4.2 Step 2: Agent Analyzes Request ................................ 8
4.3 Step 3: Agent Creates Parties ................................. 10
4.4 Step 4: Agent Authorizes Parties .............................. 12
4.4.1 Step 4a: Agent Checks Contexts .............................. 12
4.4.2 Step 4b: Agent Creates Access Control Entries ............... 13
4.5 Step 5: Agent Responds ........................................ 15
4.6 Step 6: Agent Starts Initial Inactivity Timer ................. 15
4.7 Step 7: Manager Analyzes Response ............................. 16
5 Session Destruction Algorithm ................................... 17
5.1 Step 1: Manager Requests Destruction .......................... 18
5.2 Step 2: Agent Analyzes Request and Responds ................... 18
5.3 Step 3: Manager Analyzes Response ............................. 19
6 Definitions ..................................................... 20
6.1 Administrative Assignments .................................... 21
6.2 Object Assignments ............................................ 22
6.3 Maintenance Assignments ....................................... 33
6.4 Conformance Information ....................................... 35
6.4.1 Compliance Statements ....................................... 35
6.4.2 Units of Conformance ........................................ 36
7 Appendix A: Password to Key Algorithm ........................... 37
8 Acknowledgements ................................................ 38
9 References ...................................................... 39
10 Security Considerations ........................................ 40
11 Authors' Address ............................................... 42
Expires September 1995 [Page 43]
