Re: Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt

Dan and Randy,

Below please find a new version of the Security Considerations.
Please have a look at it and tell me if it covers your concerns.

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


--On 02.07.2004 13:58 h +0200 Juergen Quittek wrote:

> Randy,
>
> Sorry, my last email slipped out of my mail editor
> while I was typing with a wrong keyboard driver.
>
>
> --On 01.07.2004 11:59 h -0700 Randy Presuhn wrote:
>
>> Hi -
>>
>>> From: "Romascanu, Dan (Dan)" <[email protected]>
>>> To: "Randy Presuhn" <[email protected]>; <[email protected]>
>>> Cc: <[email protected]>
>>> Sent: Thursday, July 01, 2004 8:41 AM
>>> Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt
>>>
>>
>>> I have some concerns with respect to the Security Considerations section.
>>> It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html),
>>> probably reflecting the style or the guidelines that were in place by the time
>>> RFC 2925 was published.
>>
>> (As WG chair) Clearly, this must be fixed before we ask our AD to take
>> it to the IESG.
>>
>> Juergen Q.: could you re-spin this before the i-d cutoff?
>
> Yes.  I am currently working on the issues raised by Eduardo.
> Fixing the security consideration should not be a big problem.
>
>>> However, I miss the clarity of the current text, and
>>> especially the enumeration of the security sensitive objects in the MIB modules,
>>> the explicit description of the risks associated with their mis-configuration or
>>> disclosure, and the explicit recommendation to deploy SNMPv3 and to enable
>>> cryptographic security.
>> ...
>>
>> (As technical contributor) I rather like the current text.  I'd like to see it retained
>> (except perhaps the first paragraph, which would become redundant) and
>> merged with the additional text required by the boilerplate.
>
> I will try to satisfy both sides: including the new boilerplate text and listing
> vulnerable objects as well as keeping all but the first paragraphs of the current
> version.
>
> Thanks,
>
>     Juergen
>
>> Randy
>>


5.  Security Considerations

   There are a number of management objects defined in the three MIB
   modules with a MAX-ACCESS clause of read-write and/or read-create.
   Such objects may be considered sensitive or vulnerable in some
   network environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  pingMaxConcurrentRequests
   o  traceRouteMaxConcurrentRequests
   o  lookupMaxConcurrentRequests
      The MIB modules limit their maximum numbers of concurrent requests
      by the values of these objects.  Unauthorized access to them may
      lead to an overload of the managed node and to a disruption of
      other functions of the managed node.

   o  pingCtlTable
   o  traceRouteCtlTable
   o  lookupCtlTable
      All objects in entries of these tables (except index objects) have
      a MAX-ACCESS clause of read-create.  Unauthorized access to these
      objects can disturb the measurements controlled by the tables.
      Also, the functions offered by the MIB modules can be misused for
      illegal data retrieval and for attacking other systems by floods
      of ping probes, traceorute probes or lookup requests,
      respectively.

   In general, both the ping and traceroute functions when used
   excessively are considered a form of system attack.  In the case of
   ping sending a system requests too often can negatively effect its
   performance or attempting to connect to what is supposed to be an
   unused port can be very unpredictable.  Excessive use of the
   traceroute capability can like ping negatively affect system
   performance.  In insecure environments it is RECOMMENDED that the
   MIBs defined within this memo not be supported.

   o  lookupPurgeTime
      Unauthorized access to this object can lead to results of lookup
      operations being deleted before they are read by a management
      system, if the object is set to 0 or small values close to 0.  If
      otherwise, the object is set to very high values, unauthorized
      access can lead to a high consumption of resources for storing
      lookup results.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly

   to even encrypt the values of these objects when sending them over
   the network via SNMP.  However, the only information that might be
   disclosed is the configuration and results of measurements that are
   performed by implementations of the MIB modules.  This information
   can only be mis-used in conjunction with the mis-use of further
   information.

   To facilitate the provisioning of access control by a security
   administrator using the View-Based Access Control Model (VACM)
   defined in RFC 3415 [RFC3415] for tables in which multiple users may
   need to independently create or modify entries, the initial index is
   used as an "owner index".  Such an initial index has a syntax of
   SnmpAdminString, and can thus be trivially mapped to a securityName
   or groupName as defined in VACM, in accordance with a security
   policy.

   All entries in related tables belonging to a particular user will
   have the same value for this initial index.  For a given user's
   entries in a particular table, the object identifiers for the
   information in these entries will have the same subidentifiers
   (except for the "column" subidentifier) up to the end of the encoded
   owner index. To configure VACM to permit access to this portion of
   the table, one would create vacmViewTreeFamilyTable entries with the
   value of vacmViewTreeFamilySubtree including the owner index portion,
   and vacmViewTreeFamilyMask "wildcarding" the column subidentifier.
   More elaborate configurations are possible.  The VACM access control
   mechanism described above provides control.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.