Definitions of Managed Objects for iSNS (Internet Storage Name Service)
draft-ietf-ips-isns-mib-11

Note: This ballot was opened for revision 11 and is now closed.

Lars Eggert Yes

(Dan Romascanu; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(David Ward; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Jon Peterson; former steering group member) No Objection

(Magnus Westerlund; former steering group member) No Objection

(Mark Townsley; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Sam Hartman; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection

The following text was contributed by Hannes Tschofenig in a Security
Directorate Review.  Please treat as Last Call comments:

I read into RFC 4171 to understand the topic a bit better since
draft-ietf-ips-isns-mib-11.txt is obviously not meant to be a good
start into the topic.

RFC 4171 obviously has a number of security relevant aspects that are
described in the security consideration section. The following aspects
are relevant for the monitoring of iSNS servers:


* Communication security aspects

This aspect relates to providing data origin authentication,
integrity, replay and confidentiality protection of data that is
transmitted between the involved entities.

The draft points to Section 8 of [RFC3410]. I am not sure whether this
is the correct section and maybe the hint is a bit unspecific. What do
I need to support in order to provide communication security?
* Unauthorized retrieval of information available via the MIB

The security requirements of draft-ietf-ips-isns-mib-11.txt mention
that the MIB contains security sensitive information that might be of
advantage for an adversary. Hence, access control may need to be
provided. The last paragraph in security consideration points to the
need for access control to ensure that only authorized entities are
able to read the MIB objects. Would it be useful to put a reference
to the User-based Security Model (USM) [RFC3414] of SNMPv3 and
to the work in progress of the ISMS working group (see
http://www.ietf.org/html.charters/isms-charter.html) with respect to
the usage of existing authentication infrastructures.  
* Unauthorized modification of data elements

RFC 4171 lists a number of security relevant elements, such as
IsnsPortalSecurityType, that impact the security of the entire system.
If an adversary would be able to modify the configuration settings of
a node then this would obviously be a serious problem (e.g., DoS,
masquerading).

As stated in the security consideration section of
draft-ietf-ips-isns-mib-11.txt there are no management objects defined
in this MIB that have a MAX-ACCESS clause of read-write and/or
read-create.

That's one possible way of dealing with a potential threat and fine
for me.