Network Working Group                                      D. Harrington
Internet-Draft                                 Huawei Technologies (USA)
Updates: 3411,3412,3414,3417                               June 29, 2007
(if approved)
Intended status: Informational
Expires: December 31, 2007


                  Security Requirements for MIB Access
                draft-harrington-mib-access-security-00

Status of This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 draft documents 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 "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 31, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.  This document describes requirements related to
   protecting the information in the Management Information Base when
   the data is being accessed or transported.



Harrington              Expires December 31, 2007               [Page 1]


Internet-Draft             MIB Access Security                 June 2007


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  The Internet-Standard Management Framework  . . . . . . . . 3
     1.2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Requirements of a MIB Data Transport Protocol . . . . . . . . . 5
     3.1.  Message Security Requirements . . . . . . . . . . . . . . . 5
       3.1.1.  Security Protocol Requirements  . . . . . . . . . . . . 5
     3.2.  Access Control Requirements . . . . . . . . . . . . . . . . 5
     3.3.  Session Requirements  . . . . . . . . . . . . . . . . . . . 5
       3.3.1.  Message security versus session security  . . . . . . . 6
   4.  Integrating with SNMPv3 . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Architectural Modularity Requirements . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8































Harrington              Expires December 31, 2007               [Page 2]


Internet-Draft             MIB Access Security                 June 2007


1.  Introduction

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.  This document describes requirements related to
   protecting the information in the Management Information Base when
   the data is being accessed or transported.

   MIB modules are written in the SMIv1 and SMIv2 data definition
   language, defined in STD 16, RFC 1155 and STD 58, RFCs 2578, 2579,
   2580.

   Management protocols provide for the exchange of messages which
   convey management information between between entities such as SNMP
   managers and SNMP agents.  SNMP has typically been the protocol for
   transferring MIB data, and SNMP version 3 is an IETF Standard that
   describes security requirements related to transporting MIB data, the
   related threats, and mechanisms to mitigate those threats.

1.1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   It is expected that readers of this document will have read RFC3410
   and RFC3411, and have a general understanding of the security-related
   functionality defined in RFCs 3412-3418.

1.2.  Conventions

   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 RFC 2119 [RFC2119].

   The key words "must", "must not", "required", "shall", "shall not",
   "should", "should not", "recommended", "may", and "optional" in this
   document are not to be interpreted as described in RFC2119.  They
   will usually, but not always, be used in a context relating to
   compatibility with the RFC3411 architecture or the subsystem defined
   here, but which might have no impact on on-the-wire compatibility.
   These terms are used as guidance for designers of proposed IETF
   models to make the designs compatible with RFC3411 subsystems and
   Abstract Service Interfaces (see section 3.2).  Implementers are free
   to implement differently.  Some usages of these lowercase terms are
   simply normal English usage.




Harrington              Expires December 31, 2007               [Page 3]


Internet-Draft             MIB Access Security                 June 2007


   Some terminology used in this document was defined as part of the
   IETF SNMPv3 Standard (STD62) or existed in normal English before the
   informational 'Internet Security Glossary' (RFC2828) was published.
   For consistency with related specifications, where necessary, this
   document favors terminology consistent with STD62 rather than with
   the Internet Security Glossary.

2.  Motivation

   The specifications of the Internet Standard Management Framework are
   based on a modular architecture.  This framework is more than just a
   protocol for moving data.  It consists of:
      * a data definition language,
      * definitions of management information (the Management
      Information Base, or MIB),
      * a protocol definition, and
      * security and administration.
   Over time, as the Framework has evolved from SNMPv1, through SNMPv2,
   to SNMPv3, the definitions of each of these architectural components
   have become richer and more clearly defined, but the fundamental
   architecture has remained consistent.  One prime motivator for this
   modularity was to enable the ongoing evolution of the Framework, as
   is documented in RFC 1052 [2].

   When originally envisioned, this capability was to be used to ease
   the transition from SNMP-based management of internets to management
   based on OSI protocols.  To this end, the framework was architected
   with a protocol-independent data definition language and Management
   Information Base along with a MIB-independent protocol.  This
   separation was designed to allow the SNMP-based protocol to be
   replaced without requiring the management information to be redefined
   or reinstrumented.

   SNMP has proven itself useful for certain management tasks,
   especially fault and performance management. but not for all
   management tasks.  The IETF has therefore chosen to develop or
   standardize additional protocols to meet the needs of other
   management tasks, such as Netconf for configuration, IPFIX for flow
   accounting, and syslog for logging.  Additional protocols may eb
   developed for other purposes.

   When RFC1052 was written, security was less of a problem in the
   Internet than it is today.  The first and second versions of SNMP
   included only trivial security, but it was soon recognized that
   access to management information could be a serious network security
   vulnerability.  SNMP version theree was developed to provide a secure
   transport for management data, plus controls to allow operators to
   configure policies regarding who is authorized to do what to which



Harrington              Expires December 31, 2007               [Page 4]


Internet-Draft             MIB Access Security                 June 2007


   subsets of the MIB.

3.  Requirements of a MIB Data Transport Protocol

3.1.  Message Security Requirements

   Protocols used to transport MIB data SHOULD provide protection
   against the following message-oriented threats [RFC3411]:

   1.  modification of information
   2.  masquerade
   3.  message stream modification
   4.  disclosure

   These threats are described in section 1.4 of [RFC3411].  It is not
   required to protect against denial of service or traffic analysis,
   but it should not make those threats significantly worse.

3.1.1.  Security Protocol Requirements

   There are a number of standard protocols that could be proposed as
   possible solutions for transporting MIB data securely.  Some factors
   SHOULD be considered when selecting a protocol.

   Using a protocol in a manner for which it was not designed has
   numerous problems.  The advertised security characteristics of a
   protocol might depend on it being used as designed; when used in
   other ways, it might not deliver the expected security
   characteristics.

   Protocols used to transport MIB data MUST be able to coexist with
   each other.

3.2.  Access Control Requirements

   RFC3411 made some design decisions related to the support of an
   Access Control Subsystem.  These include a securityName and
   securityLevel mapping, the separation of Authentication and
   Authorization, and the passing of model-independent security
   parameters.

3.3.  Session Requirements

   Some protocls might have a notion of sessions, while other protocols
   might provide channels or other session-like mechanism.  Throughout
   this document, the term session is used in a broad sense to cover
   sessions, channels, and session-like mechanisms.  Session refers to
   an association between two protocol engines that permits the



Harrington              Expires December 31, 2007               [Page 5]


Internet-Draft             MIB Access Security                 June 2007


   transmission of one or more messages within the lifetime of the
   session.  How the session is actually established, opened, closed, or
   maintained is specific to a particular protocol.

   Sessions may be considered desirable because the cost of
   authentication and integrity checking can be amortized over
   potentially many transactions.

3.3.1.  Message security versus session security

   A session is associated with state information that is maintained for
   its lifetime.  This state information allows for the application of
   various security services to multiple messages.

   Cryptographic keys established at the beginning of the session SHOULD
   be used to provide authentication, integrity checking, and encryption
   services for data that is communicated during the session.  The
   cryptographic protocols used to establish keys for a Transport Model
   session SHOULD ensure that fresh new session keys are generated for
   each session.  In addition sequence information might be maintained
   in the session which can be used to prevent the replay and reordering
   of messages within a session.  If each session uses new keys, then a
   cross-session replay attack will be unsuccessful; that is, an
   attacker cannot successfully replay on one session a message he
   observed from another session.  A good security protocol will also
   protect against replay attacks _within_ a session; that is, an
   attacker cannot successfully replay a message observed earlier in the
   same session.

   Implementations SHOULD be able to maintain some reasonable number of
   concurrent sessions.

4.  Integrating with SNMPv3

   [discuss] One approach to providing access controls for protocols
   other than SNMPv3 is to design the protocol to utilize existing SNMP
   subsystems, such as the Access Control Subsystem.

   The Access Control Subsystem can theoretically be accessed via the
   architectural ASI known as isAccessAllowed.  Implemneters may or may
   not support an actual function call to match this ASI.

   [discuss] Discuss what would be needed to utilize the existing
   isAccessAllowed ASI, how the parameters could be provided by the
   calling protocol, and the implications of using this approach.

   [discuss] some transports might be able to be managed within the
   SNMPv3 architecure as new Transport Models, as described in the ISMS



Harrington              Expires December 31, 2007               [Page 6]


Internet-Draft             MIB Access Security                 June 2007


   documents.

   [discuss] Some new protocols might be able to be designed as new
   message models in the RFC3411 architecture, possibly supported by new
   "Applications", which would permit reuse of existing secure Transport
   Models, the Transport Security Model, and existing Access Control
   Models.

4.1.  Architectural Modularity Requirements

   SNMP version 3 (SNMPv3) is based on a modular architecture (defined
   in [RFC3411] section 3) to allow the evolution of the SNMP protocol
   standards over time, and to minimize side effects between subsystems
   when changes are made.

   [todo] describe how a new protocol could fit into the existing
   architecture.

5.  Security Considerations

   This document discusses the security requirements that should be
   considered for all protocols which will carry MIB data.  The text of
   this document is, in effect, filled with Security Considerations.

6.  IANA Considerations

   This document requires no action by IANA.

7.  Acknowledgments

   The auithor would like to thank the following people for their
   contributions:

8.  References

8.1.  Normative References

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

   [RFC3411]                                 Harrington, D., Presuhn,
                                             R., and B. Wijnen, "An
                                             Architecture for Describing
                                             Simple Network Management
                                             Protocol (SNMP) Management



Harrington              Expires December 31, 2007               [Page 7]


Internet-Draft             MIB Access Security                 June 2007


                                             Frameworks", STD 62,
                                             RFC 3411, December 2002.

   [RFC3412]                                 Case, J., Harrington, D.,
                                             Presuhn, R., and B. Wijnen,
                                             "Message Processing and
                                             Dispatching for the Simple
                                             Network Management Protocol
                                             (SNMP)", STD 62, RFC 3412,
                                             December 2002.

   [RFC3414]                                 Blumenthal, U. and B.
                                             Wijnen, "User-based
                                             Security Model (USM) for
                                             version 3 of the Simple
                                             Network Management Protocol
                                             (SNMPv3)", STD 62,
                                             RFC 3414, December 2002.

   [RFC3417]                                 Presuhn, R., "Transport
                                             Mappings for the Simple
                                             Network Management Protocol
                                             (SNMP)", STD 62, RFC 3417,
                                             December 2002.

8.2.  Informative References

   [RFC2865]                                 Rigney, C., Willens, S.,
                                             Rubens, A., and W. Simpson,
                                             "Remote Authentication Dial
                                             In User Service (RADIUS)",
                                             RFC 2865, June 2000.

   [RFC3410]                                 Case, J., Mundy, R.,
                                             Partain, D., and B.
                                             Stewart, "Introduction and
                                             Applicability Statements
                                             for Internet-Standard
                                             Management Framework",
                                             RFC 3410, December 2002.

   [RFC4346]                                 Dierks, T. and E. Rescorla,
                                             "The Transport Layer
                                             Security (TLS) Protocol
                                             Version 1.1", RFC 4346,
                                             April 2006.

   [RFC4422]                                 Melnikov, A. and K.



Harrington              Expires December 31, 2007               [Page 8]


Internet-Draft             MIB Access Security                 June 2007


                                             Zeilenga, "Simple
                                             Authentication and Security
                                             Layer (SASL)", RFC 4422,
                                             June 2006.

   [RFC4251]                                 Ylonen, T. and C. Lonvick,
                                             "The Secure Shell (SSH)
                                             Protocol Architecture",
                                             RFC 4251, January 2006.

   [RFC4741]                                 Enns, R., "NETCONF
                                             Configuration Protocol",
                                             RFC 4741, December 2006.

   [I-D.ietf-isms-transport-security-model]  Harrington, D., "Transport
                                             Security Model for SNMP", d
                                             raft-ietf-isms-transport-
                                             security-model-04 (work in
                                             progress), May 2007.

Author's Address

   David Harrington
   Huawei Technologies (USA)
   1700 Alma Dr. Suite 100
   Plano, TX 75075
   USA

   Phone: +1 603 436 8634
   EMail: dharrington@huawei.com





















Harrington              Expires December 31, 2007               [Page 9]


Internet-Draft             MIB Access Security                 June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Harrington              Expires December 31, 2007              [Page 10]