rfc2786.txt

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

-- Conformance Information

usmDHKeyMIBCompliances  OBJECT IDENTIFIER ::= { usmDHKeyConformance 1 }
usmDHKeyMIBGroups       OBJECT IDENTIFIER ::= { usmDHKeyConformance 2 }

-- Compliance statements

usmDHKeyMIBCompliance   MODULE-COMPLIANCE
    STATUS      current
    DESCRIPTION
        "The compliance statement for this module."
    MODULE
        GROUP usmDHKeyMIBBasicGroup
        DESCRIPTION
        "This group MAY be implemented by any agent which
        implements the usmUserTable and which wishes to provide the
        ability to change user and agent authentication and privacy
        keys via Diffie-Hellman key exchanges."

        GROUP usmDHKeyParamGroup
        DESCRIPTION
            "This group MUST be implemented by any agent which
        implements a MIB containing the DHKeyChange Textual
        Convention defined in this module."

        GROUP usmDHKeyKickstartGroup
        DESCRIPTION
            "This group MAY be implemented by any agent which
        implements the usmUserTable and which wishes the ability to
        populate the USM table based on out-of-band provided DH
        ignition values.



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


             Any agent implementing this group is expected to provide
        preinstalled entries in the vacm tables as follows:

             In the usmUserTable: This entry allows access to the
        system and dhKickstart groups

        usmUserEngineID         localEngineID
        usmUserName             'dhKickstart'
        usmUserSecurityName     'dhKickstart'
        usmUserCloneFrom        ZeroDotZero
        usmUserAuthProtocol     none
        usmUserAuthKeyChange    ''
        usmUserOwnAuthKeyChange ''
        usmUserPrivProtocol     none
        usmUserPrivKeyChange    ''
        usmUserOwnPrivKeyChange ''
        usmUserPublic           ''
        usmUserStorageType      permanent
        usmUserStatus           active

            In the vacmSecurityToGroupTable: This maps the initial
        user into the accessible objects.

        vacmSecurityModel               3 (USM)
        vacmSecurityName                'dhKickstart'
        vacmGroupName                   'dhKickstart'
        vacmSecurityToGroupStorageType  permanent
        vacmSecurityToGroupStatus       active

            In the vacmAccessTable: Group name to view name translation.

        vacmGroupName                   'dhKickstart'
    vacmAccessContextPrefix             ''
        vacmAccessSecurityModel         3 (USM)
        vacmAccessSecurityLevel         noAuthNoPriv
        vacmAccessContextMatch          exact
        vacmAccessReadViewName          'dhKickRestricted'
        vacmAccessWriteViewName         ''
        vacmAccessNotifyViewName        'dhKickRestricted'
        vacmAccessStorageType           permanent
        vacmAccessStatus                active

            In the vacmViewTreeFamilyTable: Two entries to allow the
        initial entry to access the system and kickstart groups.

        vacmViewTreeFamilyViewName      'dhKickRestricted'
        vacmViewTreeFamilySubtree       1.3.6.1.2.1.1  (system)
        vacmViewTreeFamilyMask          ''



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


        vacmViewTreeFamilyType          1
        vacmViewTreeFamilyStorageType   permanent
        vacmViewTreeFamilyStatus        active

        vacmViewTreeFamilyViewName      'dhKickRestricted'
        vacmViewTreeFamilySubtree         (usmDHKickstartTable OID)
        vacmViewTreeFamilyMask          ''
        vacmViewTreeFamilyType          1
        vacmViewTreeFamilyStorageType   permanent
        vacmViewTreeFamilyStatus        active
        "

        OBJECT usmDHParameters
        MIN-ACCESS      read-only
        DESCRIPTION
            "It is compliant to implement this object as read-only for
        any device."

    ::= { usmDHKeyMIBCompliances 1 }

-- Units of Compliance

usmDHKeyMIBBasicGroup OBJECT-GROUP
    OBJECTS     {
                  usmDHUserAuthKeyChange,
                  usmDHUserOwnAuthKeyChange,
                  usmDHUserPrivKeyChange,
                  usmDHUserOwnPrivKeyChange
                }
    STATUS      current
    DESCRIPTION
        ""
    ::= { usmDHKeyMIBGroups 1 }

usmDHKeyParamGroup OBJECT-GROUP
    OBJECTS     {
                  usmDHParameters
                }
    STATUS      current
    DESCRIPTION
        "The mandatory object for all MIBs which use the DHKeyChange
    textual convention."
    ::= { usmDHKeyMIBGroups 2 }

usmDHKeyKickstartGroup OBJECT-GROUP
    OBJECTS     {
                  usmDHKickstartMyPublic,
                  usmDHKickstartMgrPublic,



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


                  usmDHKickstartSecurityName
                }
    STATUS      current
    DESCRIPTION
        "The objects used for kickstarting one or more SNMPv3 USM
    associations via a configuration file or other out of band,
    non-confidential access."
    ::= { usmDHKeyMIBGroups 3 }


END

4.  References

   [1]  Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
        Describing SNMP Management Frameworks", RFC 2571, April 1999.

   [2]  Rose, M. and K. McCloghrie, "Structure and Identification of
        Management Information for TCP/IP-based Internets", STD 16, RFC
        1155, May 1990.

   [3]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
        RFC 1212, March 1991.

   [4]  Rose, M., "A Convention for Defining Traps for use with the
        SNMP", RFC 1215, March 1991.

   [5]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,  J.,
        Rose, M. and S. Waldbusser, "Structure of Management Information
        Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [6]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,  J.,
        Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD
        58, RFC 2579, April 1999.

   [7]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
        M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
        58, RFC 2580, April 1999.

   [8]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
        Network Management Protocol", STD 15, RFC 1157, May 1990.

   [9]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
        "Introduction to Community-based SNMPv2", RFC 1901, January
        1996.






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


   [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
        Mappings for Version 2 of the Simple Network Management Protocol
        (SNMPv2)", RFC 1906, January 1996.

   [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
        Processing and Dispatching for the Simple Network Management
        Protocol (SNMP)", RFC 2572, April 1999.

   [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
        for version 3 of the Simple Network Management Protocol
        (SNMPv3)", RFC 2574, April 1999.

   [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
        Operations for Version 2 of the Simple Network Management
        Protocol (SNMPv2)", RFC 1905, January 1996.

   [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
        2573, April 1999.

   [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
        Control Model (VACM) for the Simple Network Management Protocol
        (SNMP)", RFC 2575, April 1999.

   [16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [17] "Diffie-Hellman Key-Agreement Standard, Version 1.4", PKCS #3,
        RSA Laboratories, November 1993.

   [18] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC
        2409, November 1988.

   [19] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
        Recommendations for Security", RFC 1750, December 1994.

5.  Security Considerations

   Objects in the usmDHUserKeyTable should be considered to have the
   same security sensitivity as the objects of the KeyChange type in
   usmUserTable and should be afforded the same level of protection.
   Specifically, the VACM should not grant more or less access to these
   objects than it grants to the usmUserTable KeyChange object.

   The improper selection of parameters for use with Diffie-Hellman key
   changes may adversely affect the security of the agent.  Please see
   the body of the MIB for specific recommendations or requirements on
   the selection of the DH parameters.




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


   An unauthenticated DH exchange is subject to "man-in-the-middle"
   attacks.  The use of the DH exchange in any specific environment
   should balance risk versus threat.

   Good security from a DH exchange requires a good source of random
   numbers.  If your application cannot provide a reasonable source of
   randomness, do not use a DH exchange.  For more information, see
   "Randomness Recommendations for Security" [19].

6.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

7.  Author's Address

   Michael C. StJohns
   Excite@Home
   450 Broadway
   Redwood City, CA 94063
   USA

   Phone: [phone]
   EMail: [e-mail]










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


9.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















St. Johns                     Experimental                     [Page 20]