Diffie-Helman USM Key Management Information Base and Textual Convention
RFC 2786
|
| Document |
Type |
|
RFC - Experimental
(March 2000; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
RFC 2786 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Steven Bellovin
|
|
Send notices to |
|
<rweltman@netscape.com>
|
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
Show full document text