[midcom] RE: Security recommendations in MIDCOM MIB draft

"David B Harrington" <dbharrington@comcast.net> Sun, 12 August 2007 19:22 UTC

Return-path: <midcom-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKJ1a-00020G-9Q; Sun, 12 Aug 2007 15:22:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITX4-0003ze-PZ for midcom@ietf.org; Tue, 07 Aug 2007 14:11:50 -0400
Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IITX3-0005md-EG for midcom@ietf.org; Tue, 07 Aug 2007 14:11:50 -0400
Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070807181148b1100r345de>; Tue, 7 Aug 2007 18:11:48 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Romascanu, Dan \(Dan\)'" <dromasca@avaya.com>, "'Bert Wijnen'" <bwijnen@lucent.com>
References: <030a01c7d885$a2da3d50$6702a8c0@china.huawei.com> <EDC652A26FB23C4EB6384A4584434A042C877C@307622ANEX5.global.avaya.com>
Date: Tue, 7 Aug 2007 14:11:35 -0400
Message-ID: <046301c7d91e$64873fa0$6702a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <EDC652A26FB23C4EB6384A4584434A042C877C@307622ANEX5.global.avaya.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-index: AcfYhCohAq3XquADRW2AqDrVtJ4o6QAALkkQABV3DQAAA9RfAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73f7847c44628482de9d5f1018acf469
X-Mailman-Approved-At: Sun, 12 Aug 2007 15:22:52 -0400
Cc: midcom@ietf.org
Subject: [midcom] RE: Security recommendations in MIDCOM MIB draft
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Errors-To: midcom-bounces@ietf.org

Hi Dan,

You should realize that Juergen Q asked me to comment on the issue
raised by Tim Polk's DISCUSS about requiring SNMPv3. 

Your point about the apparent conflict in my statements did not elude
me. I am copying the midcom list so the midcom list sees this
clarification as well.

here is a subtle distinction in the two points
1) It is inappropriate to REQUIRE SNMPv3 be used with a particular MIB
module. 
2) The WG can specify a mandatory-to-implement mechanism to ensure
interoperability of threat mitigation for compliant implementations.

The MIDCOM-MIB module itself must not require any particular SNMP
version, in order to allow for "protocol agility". Recognize that in a
master/subagent implementation, the MIB module implementation (a
subagent) may have no way to determine which protocol (or version) was
used by the master agent to receive the request and will be used to
send the response or notification. There should be a real separation
between the MIB and the protocol. The SMI defines the datatypes and
the addressing mechanism, which are then used in both the MIB
implementation and the protocol. 

It is perfectly acceptable for a standards-track document to specify a
mandatory-to-implement feature of the standard. Using VACM as an
example, it is not acceptable for the VACM-MIB to require that only
SNMPv3 messages be used to carry VACM management objects, but it is
acceptable to mandate VACM as the
mandatory-to-implement-for-interoperability access control model of
the SNMPv3 standard. The MIDCOM-MIB module should not say it must only
be used with the SNMPv3 protocol; the MIDCOM standard should say the
mandatory-to-implement-for-interoperability protocol for configurating
the MIDCOM-MIB module is SNMPv3. 

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
> Sent: Tuesday, August 07, 2007 6:17 AM
> To: David B Harrington; Bert Wijnen
> Subject: RE: Security recommendations in MIDCOM MIB draft
> 
> All looks fine to me, wit the exception of: 
> 
> > It is inappropriate to REQUIRE SNMPv3 be used with a 
> > particular MIB module. 
> 
> Actually I believe that in this specific case the MIDCOM MIB comes
> together with the selection of SNMP as MIDCOM protocol and 
> using SNMPv3
> with cryptography enabled is the only way of implementing a 
> secure push
> of the configuration of MIDCOM devices. 
> 
> And anyway the above seems to be in conflict with: 
> 
> > 4) The WG can specify a mandatory-to-implement mechanism to 
> > ensure interoperability of threat mitigation for compliant 
> > implementations.
> > So I believe it is appropropriate to specify SNMPv3 (with 
> > VACM) as a mandatory-to-implement feature of compliant 
> > implementations for purposes of interoperability, if the WG 
> > chooses to do so.
> 
> One more observation. This document is at a second run in the IESG.
It
> is now pending on one DISCUSS from new AD Tim Polk, otherwise it
would
> have been already approved. My position is NO OBJECTION now, I had
my
> own objections which were dealt with, but it would be good if you
guys
> and other MIB Doctors would catch such documents in time for me to
> submit comments - in time meaning when I am forwarding the 
> IESG telechat
> agendas prior to each bi-weekly telechat. 
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: David B Harrington [mailto:dbharrington@comcast.net] 
> > Sent: Tuesday, August 07, 2007 2:58 AM
> > To: 'Bert Wijnen'; Romascanu, Dan (Dan)
> > Subject: FW: Security recommendations in MIDCOM MIB draft
> > 
> > Hi,
> > 
> > I just sent this advice to the MIDCOM WG in response to the 
> > thread at 
> >
http://www1.ietf.org/mail-archive/web/midcom/current/msg03902.html.
> > You might want to review it to see if you agree with my advice.
> > 
> > dbh
> > 
> > -----Original Message-----
> > From: David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Monday, August 06, 2007 7:48 PM
> > To: midcom@ietf.org
> > Subject: Security recommendations in MIDCOM MIB draft
> > 
> > Hi,
> > 
> > Juergen Q asked me to wade into this discussion. I was 
> co-chair of the
> > SNMPv3 WG, am a MIB Doctor and a Security Directorate member, 
> > and an editor in the ISMS WG. My response is wordy, but I 
> > choose to point to the relevant references for my recommendations.
> > 
> > The official security recommendations concerning SNMP 
> > versions is found in the following official boilerplate for 
> > MIB documents, from
> > http://www.ops.ietf.org/mib-security.html:
> > 
> > "X. Security Considerations
> > 
> > -- if you have any read-write and/or read-create objects, please
> > -- describe their specific sensitivity or vulnerability.
> > -- RFC 2669 has a very good example.
> > 
> >    There are a number of management objects defined in this 
> MIB module
> >    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:
> > 
> >     <list the tables and objects and state why they are sensitive>
> > 
> > -- else if there are no read-write objects in your MIB module
> > 
> >    There are no management objects defined in this MIB module 
> > that have
> >    a MAX-ACCESS clause of read-write and/or read-create.  
> So, if this
> >    MIB module is implemented correctly, then there is no 
> risk that an
> >    intruder can alter or create any management objects of this MIB
> >    module via direct SNMP SET operations.
> > 
> > -- for all MIB modules you must evaluate whether any 
> readable objects
> > -- are sensitive or vulnerable (for instance, if they might reveal
> > -- customer information or violate personal privacy laws such as
> > -- those of the European Union if exposed to unathorized parties)
> > 
> >    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.  These are the tables and objects and
their
> >    sensitivity/vulnerability:
> > 
> >     <list the tables and objects and state why they are sensitive>
> > 
> >    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."
> > 
> > 
> > This security boilerplate was worked out in negotiations 
> > between the OPS area directors and the Security area 
> > directors, and is very carefully worded. MIB Doctors have 
> > been trained to look closely at any modifications to the text 
> > of the boilerplate to ensure the meaning has not been changed 
> > in any way. Except for filling in the lists of objects and 
> > explanations of the vulnerabilities, I recommend using the 
> > text of the boilerplate as is.
> > 
> > RFC4181 "Guidelines for Authors and Reviewers of MIB Documents"
> > describes this further:
> > "3.4.  Security Considerations Section
> > 
> >    Each specification that defines one or more MIB modules 
> > MUST contain
> >    a section that discusses security considerations 
> relevant to those
> >    modules.  This section MUST be patterned after the 
> latest approved
> >    template (available at 
> http://www.ops.ietf.org/mib-security.html).
> >    In particular, writable MIB objects that could be especially
> >    disruptive if abused MUST be explicitly listed by name and the
> >    associated security risks MUST be spelled out; 
> similarly, readable
> >    MIB objects that contain especially sensitive information or
that
> >    raise significant privacy concerns MUST be explicitly 
> > listed by name
> >    and the reasons for the sensitivity/privacy concerns MUST be
> >    explained.  If there are no risks/vulnerabilities for a
specific
> >    category of MIB objects, then that fact MUST be 
> explicitly stated.
> >    Failure to mention a particular category of MIB objects 
> will not be
> >    equated to a claim of no risks/vulnerabilities in that
category;
> >    rather, it will be treated as an act of omission and 
> will result in
> >    the document being returned to the author for 
> correction.  Remember
> >    that the objective is not to blindly copy text from the 
> > template, but
> >    rather to think and evaluate the risks/vulnerabilities and then
> >    state/document the result of this evaluation."
> > 
> > Here are some considerations that may not necessarily appear 
> > obvious in the boilerplate, and my recommendations for how 
> to proceed:
> > 
> > 1) A MIB module should not require a specific version of the 
> > SNMP protocol (or even a specific protocol). RFC1052 
> > describes the architectural separation of the protocol from 
> > the MIB, with a binding through the SMI, to allow for 
> > multiple protocols to have access to MIB data, and RFC3410 
> > discusses this further as relates to SNMP versions. 
> > 
> > Note that an implementation of a MIB module may actually have 
> > no way to detect which version of SNMP, or which protocol, is 
> > used to transport the MIB data.
> > 
> > As Wes points out in one of his comments, Netconf is a 
> > protocol in development that may utilize access to the MIB data. 
> > 
> > It is inappropriate to REQUIRE SNMPv3 be used with a 
> > particular MIB module. 
> > 
> > 2) As RFC4181 points out, it is required to utilize/mirror 
> > the recommendations found in the security considerations 
> > boilerplate for MIB modules 
> > (http://www.ops.ietf.org/mib-security.html), including the 
> > discussion of SNMP versions.
> > 
> > 3) The WG must identify the security threats that SHOULD be 
> > mitigated during deployment, identify which MIB objects are 
> > vulnerable to which threats, and what the implications of the 
> > vulnerabilities are. 
> > 
> > 4) The WG can specify a mandatory-to-implement mechanism to 
> > ensure interoperability of threat mitigation for compliant 
> > implementations.
> > So I believe it is appropropriate to specify SNMPv3 (with 
> > VACM) as a mandatory-to-implement feature of compliant 
> > implementations for purposes of interoperability, if the WG 
> > chooses to do so.
> > 
> > 5) It is up to operators to make the decision whether to 
> > **use** the provided mandatory-to-implement mechanism. It is 
> > inappropriate to REQUIRE that operators use a particular 
> > mechanism to mitigate the threats. 
> > 
> > 6) Concerned firewall operators can protect their deployment 
> > by defining appropriate MIB controls for GET/SET access to 
> > the MIDCOM MIB. 
> > 
> > 7) SNMPv3 provides a mandatory-to-implement mechanism (VACM, 
> > defined in RFC3415) for controlling access to MIB objects. 
> > VACM protection can include denying access to the MIDCOM MIB 
> > for protocols and protocol versions utilizing security other 
> > than the SNMPv3-mandatory-to-implement USM security model.
> > 
> > 8) To support additional security models (such as those being 
> > developed in ISMS), VACM protection can include denying 
> > access to the MIDCOM MIB for protocols and protocol versions 
> > utilizing security levels other than those that provide 
> > authentication and encryption.
> > The securityModel column in the vacmAccessTable can be set to
"any"
> > while the securityLevel column can be set to authPriv, so 
> > only messages that have been authenticated and encrypted will 
> > be permitted access. Since the SNMPv1 and SNMPv2 security 
> > models (RFC3584) are defined as not providing authentication 
> > and encryption, requests coming through the SNMPv1 and SNMPv2 
> > security models would not be granted access, but requests 
> > secured using USM or the ISMS WG's Transport Security Model 
> > would be granted access.
> > 
> > 9) Juergen is accurate that configuring VACM is potentially 
> > time-consuming and error-prone and might test the SNMPv3 
> > configuration skills of administrators. I suggest that the 
> > MIDCOM WG develop a recommended set of VACM entries in an 
> > appendix to provide the recommended VACM access controls, so 
> > each administrator does not need to figure this out for 
> > themselves. The WG should have this recommended VACM 
> > configuration reviewed by MIB Doctors who do have strong 
> > SNMPv3 skills. 
> > 
> > 10) I believe it would be appropriate to specify the 
> > recommended VACM configuration as a mandatory to implement 
> > default configuration for VACM for MIDCOM-MIB compliant 
> > implementations. The mandatory-to-implement configuration 
> > should be allowed to be enabled/disabled or modified by 
> > administrators.
> > 
> > I hope this wordy response is helpful. ;-)
> > 
> > David Harrington
> > dbharrington@comcast.net
> > ietfdbh@comcast.net
> > 
> > 
> > 
> 



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom