rfc2786.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        M. St. Johns
Request for Comments: 2786                                    Excite@Home
Category: Experimental                                         March 2000


                         Diffie-Helman USM Key
           Management Information Base and Textual Convention

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

IESG Note

   This document specifies an experimental MIB. Readers, implementers
   and users of this MIB should be aware that in the future the IETF may
   charter an IETF Working Group to develop a standards track MIB to
   address the same problem space that this MIB addresses.  It is quite
   possible that an incompatible standards track MIB may result from
   that effort.

Abstract

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   the Internet community.  In particular, it defines a textual
   convention for doing Diffie-Helman key agreement key exchanges and a
   set of objects which extend the usmUserTable to permit the use of a
   DH key exchange in addition to the key change method described in
   [12]. In otherwords, this MIB adds the possibility of forward secrecy
   to the USM model.  It also defines a set of objects that can be used
   to kick start security on an SNMPv3 agent when the out of band path
   is authenticated, but not necessarily private or confidential.

   The KeyChange textual convention described in [12] permits secure key
   changes, but has the property that if a third-party has knowledge of
   the original key (e.g. if the agent was manufactured with a standard
   default key) and could capture all SNMP exchanges, the third-party
   would know the new key.  The Diffie-Helman key change described here





St. Johns                     Experimental                      [Page 1]

RFC 2786                 Diffie-Helman USM Key                March 2000


   limits knowledge of the new key to the agent and the manager making
   the change.  In otherwords, this process adds forward secrecy to the
   key change process.

   The recommendation in [12] is that the usmUserTable be populated out
   of band - e.g. not via SNMP.  If the number of agents to be
   configured is small, this can be done via a console port and
   manually.  If the number of agents is large, as is the case for a
   cable modem system, the manual approach doesn't scale well.  The
   combination of the two mechanisms specified here - the DH key change
   mechanism, and the DH key ignition mechanism - allows managable use
   of SNMPv3 USM in a system of millions of devices.

   This memo specifies a MIB module in a manner that is compliant to the
   SNMP SMIv2[5][6][7].  The set of objects is consistent with the SNMP
   framework and existing SNMP standards and is intended for use with
   the SNMPv3 User Security Model MIB and other security related MIBs.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [16].

   This memo is a private submission by the author, but is applicable to
   the SNMPv3 working group within the Internet Engineering Task Force.
   Comments are solicited and should be addressed to the the author.

Table of Contents

   1 The SNMP Management Framework .................................   2
   1.1 Structure of the MIB ........................................   3
   2 Theory of Operation ...........................................   4
   2.1 Diffie-Helman Key Changes ...................................   4
   2.2 Diffie-Helman Key Ignition ..................................   4
   3 Definitions ...................................................   6
   4 References ....................................................  17
   5 Security Considerations .......................................  18
   6 Intellectual Property .........................................  19
   7 Author's Address ..............................................  19
   8 Full Copyright Statement ......................................  20

1.  The SNMP Management Framework   The SNMP Management Framework
   presently consists of five major components:

   o   An overall architecture, described in RFC 2271 [1].

   o   Mechanisms for describing and naming objects and events for the
       purpose of management. The first version of this Structure of
       Management Information (SMI) is called SMIv1 and described in STD



St. Johns                     Experimental                      [Page 2]

RFC 2786                 Diffie-Helman USM Key                March 2000


       16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
       second version, called SMIv2, is described in STD 58, RFC 2578
       [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].

   o   Message protocols for transferring management information. The
       first version of the SNMP message protocol is called SNMPv1 and
       described in STD 15, RFC 1157 [8]. A second version of the SNMP
       message protocol, which is not an Internet standards track
       protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
       1906 [10].  The third version of the message protocol is called
       SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274
       [12].

   o   Protocol operations for accessing management information. The
       first set of protocol operations and associated PDU formats is
       described in STD 15, RFC 1157 [8]. A second set of protocol
       operations and associated PDU formats is described in RFC 1905
       [13].

   o   A set of fundamental applications described in RFC 2273 [14] and
       the view-based access control mechanism described in RFC 2275
       [15].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

1.1.  Structure of the MIB

   This MIB is structured into three groups and a single textual
   convention:

   o   The DHKeyChange textual convention defines the process for
       changing a secret key value via a Diffie-Helman key exchange.

   o   The usmDHPublicObjects group contains a single object which
       describes the public Diffie-Helman parameters required by any
       instance of a DHKeyChange typed object.



St. Johns                     Experimental                      [Page 3]

RFC 2786                 Diffie-Helman USM Key                March 2000


   o   The usmDHUserKeyTable augments and extends the usmUserTable
       defined in the SNMPv3 User-based Security Model MIB [12] by
       providing objects which permit the updating of the Authentication
       and Privacy keys for a row in this table through the use of a
       Diffie-Helman key exchange.

   o   The usmDHKickstartTable provides a mechanism for a management
       station to be able to agree upon a set of authentication and
       confidentiality keys and their associated row in the
       usmUserTable.

2.  Theory of Operation

2.1.  Diffie-Helman Key Changes

   Upon row creation (in the usmUserTable), or object change (either of
   the object in the usmDHUserKeyTable or its associated value in the
   usmUserTable), the agent generates a random number.  From this random
   number, the agent uses the DH parameters and transforms to derive a
   DH public value which is then published to the associated MIB object.
   The management station reads one or more of the objects in the
   usmDHUserKeyTable to get the agent's DH public values.

   The management station generates a random number, derives a DH public
   value from that random number (as described in the DHKeyChange
   Textual Convention), and does an SNMP SET against the object in the
   usmDHUserKeyTable.  The set consists of the concatenation of the
   agent's derived DH public value and the manager's derived DH public
   value (to ensure the DHKeyChange object hasn't otherwise changed in
   the meantime).

   Upon successful completion of the set, the underlying key
   (authentication or confidentiality) for the associated object in the
   usmUserTable is changed to a key derived from the DH shared secret.
   Both the agent and the management station are able to calculate this
   value based on their knowledge of their own random number and the
   other's DH public number.

2.2.  Diffie-Helman Key Ignition

   [12] recommends that the usmUserTable be populated out of band, for
   example - manually.  This works reasonably well if there are a small
   number of agents, or if all the agents are using the same key
   material, and if the device is physically accessible for that action.
   It does not scale very well to the case of possibly millions of
   devices located in thousands of locations in hundreds of markets in





St. Johns                     Experimental                      [Page 4]

RFC 2786                 Diffie-Helman USM Key                March 2000


   multiple countries.  In other words, it doesn't work well with a
   cable modem system, and may not work all that well with other large-
   scale consumer broadband IP offerings.

   The methods described in the objects under the usmDHKickstartGroup
   can be used to populate the usmUserTable in the circumstances where
   you may be able to provide at least limited integrity for the
   provisioning process, but you can't guarantee confidentiality.  In
   addition, as a side effect of using the DH exchange, the operational
   USM keys for each agent will differ from the operational USM keys for
   every other device in the system, ensuring that compromise of one
   device does not compromise the system as a whole.

   The vendor who implements these objects is expected to provide one or
   more usmSecurityNames which map to a set of accesses defined in the
   VACM [15] tables.  For example, the vendor may provide a 'root' user
   who has access to the entire device for read-write, and 'operator'
   user who has access to the network specific monitoring objects and
   can also reset the device, and a 'customer' user who has access to a
   subset of the monitoring objects which can be used to help the
   customer debug the device in conjunction with customer service
   questions.

   To use, the system manager (the organization or individual who own
   the group of devices) generates one or more random numbers - R.  The
   manager derives the DH Public Numbers R' from these random numbers,
   associates the public numbers with a security name, and configures
   the agent with this association.  The configuration would be done
   either manually (in the case of a small number of devices), or via
   some sort of distributed configuration file.  The actual mechanism is
   outside the scope of this document.  The agent in turn generates a
   random number for each name/number pair, and publishes the DH Public
   Number derived from its random number in the usmDHKickstartTable
   along with the manager's public number and provided security name.

   Once the agent is initialized, an SNMP Manager can read the contents
   of the usmDHKickstartTable using the security name of 'dhKickstart'
   with no authentication.  The manager looks for one or more entries in
   this table where it knows the random number used to derive the
   usmDHKickstartMgrPublic number.  Given the manager's knowledge of the
   private random number, and the usmDHKickstartMyPublic number, the
   manager can calculate the DH shared secret.  From that shared secret,
   it can derive the operational authentication and confidentiality keys
   for the usmUserTable row which has the matching security name.  Given
   the keys and the security name, the manager can then use normal USM
   mechanisms to access the remainder of the agent's MIB space.





St. Johns                     Experimental                      [Page 5]

RFC 2786                 Diffie-Helman USM Key                March 2000


3.  Definitions

SNMP-USM-DH-OBJECTS-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    -- OBJECT-IDENTITY,
    experimental, Integer32
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF
    usmUserEntry
        FROM SNMP-USER-BASED-SM-MIB
    SnmpAdminString
        FROM SNMP-FRAMEWORK-MIB;

snmpUsmDHObjectsMIB MODULE-IDENTITY
    LAST-UPDATED "200003060000Z"  -- 6 March 2000, Midnight
    ORGANIZATION "Excite@Home"
    CONTACT-INFO "Author: Mike StJohns
                  Postal: Excite@Home
                          450 Broadway
                          Redwood City, CA 94063
                  Email:  [e-mail]
                  Phone:  [phone]"

    DESCRIPTION
        "The management information definitions for providing forward
    secrecy for key changes for the usmUserTable, and for providing a
    method for 'kickstarting' access to the agent via a Diffie-Helman
    key agreement."

    REVISION     "200003060000Z"
    DESCRIPTION
       "Initial version published as RFC 2786."


    ::= { experimental 101 }  -- IANA DHKEY-CHANGE 101

-- Administrative assignments

usmDHKeyObjects OBJECT IDENTIFIER ::= { snmpUsmDHObjectsMIB 1 }
usmDHKeyConformance OBJECT IDENTIFIER ::= { snmpUsmDHObjectsMIB 2 }

-- Textual conventions




St. Johns                     Experimental                      [Page 6]

RFC 2786                 Diffie-Helman USM Key                March 2000


DHKeyChange ::=         TEXTUAL-CONVENTION
    STATUS              current
    DESCRIPTION
        "Upon initialization, or upon creation of a row containing an
    object of this type, and after any successful SET of this value, a
    GET of this value returns 'y' where y = g^xa MOD p, and where g is
    the base from usmDHParameters, p is the prime from
    usmDHParameters, and xa is a new random integer selected by the
    agent in the interval 2^(l-1) <= xa < 2^l < p-1.  'l' is the
    optional privateValueLength from usmDHParameters in bits.  If 'l'
    is omitted, then xa (and xr below) is selected in the interval 0
    <= xa < p-1.  y is expressed as an OCTET STRING 'PV' of length 'k'
    which satisfies

              k
        y =  SUM   2^(8(k-i)) PV'i
             i=1

        where PV1,...,PVk are the octets of PV from first to last, and
        where PV1 <> 0.

    A successful SET consists of the value 'y' expressed as an OCTET
    STRING as above concatenated with the value 'z'(expressed as an
    OCTET STRING in the same manner as y) where z = g^xr MOD p, where
    g, p and l are as above, and where xr is a new random integer
    selected by the manager in the interval 2^(l-1) <= xr < 2^l <
    p-1. A SET to an object of this type will fail with the error
    wrongValue if the current 'y' does not match the 'y' portion of
    the value of the varbind for the object. (E.g. GET yout, SET
    concat(yin, z), yout <> yin).

    Note that the private values xa and xr are never transmitted from
    manager to device or vice versa, only the values y and z.