Subject: [Ips] IPS Authorization MIB

From: "David B Harrington" <[email-masked]>
Date: Thu, 27 Jan 2005 22:06:44 -0500

Hi,

A few comments after a very quick read:
I have some concerns with the whole concept of having a table of
security identities and credentials. This is a tremendous security
weakness if not properly protected. You should have a LOT of
discussion in the text about the security threats to consider and how
they can be mitigated. Since you intend this for multipel protocols to
share, you will probably need to be really specific about the security
protections that any using protocol MUST abide when using this mib
module. If any other rotocol has the ability to modify this table,
then you should discuss at least all the threats discussed in the
SNMPv3 architecture document.

Assuming you can address this issue adequately, here are some design
specifics to consider:

1) There is a movement afoot to discourage normative references to
SMIv1 mib documents. You should try to use normative references to
only SMIv2 mib documents if possible; try not to reference RFC1213,
for instance. 
2) the discussion of ipsAuthInstance mentions a number of ways to
partition that data (partitioning, stackables, etc.). In SNMP,
contexts serve this purpose. It would probably be a good thing to
discuss how contexts would serve this purpose for your mib. Contexts
are an important aspect of SNMP security.
3) the index into ipsAuthInstanceAttributesEntry is a part of the
public interface (to use an O-O term), which means it is used by
management stations. If this can change across reboots, this could be
problematic. It is best if this doesn't change across reboots, but if
it does, you need to provide a non-changing identifier so management
stations can correlate the information. This was done with the IF-MIB
to accommodate ifIndex changes on reboots, but has proven difficult
and should be avoided if possible, especially on writable tables. If
you permit the indicies to change across reboots, you need to limit
reuse of indices to prevent the case where a manager reads the table,
selects a row to modify (or create), the system reboots, and the
manager modifies the wrong row of data. Typically this can be hanlded
by using monotonically incrementing indices that are not reused until
the whole range of possible indices has been used. A
nextAvailableIndex scalar also might help.
4) I suggest that relationship to other mib modules should at least
discuss how this table relates to the USM mib, which also contains a
list of users for authentication/authorization purposes for SNMP.
5) "An entry in this table is typically referenced by its name
(ipsAuthInstDescr), which should be displayed to the user by the
management station." If this is the way you expect the rows to be
refernced, why haven't you indexed the row by this field? Note that
there is no requirement in your mib that this descr be unique, so if
this table is referenced by this field, what happens when there is
duplication?
6) You suggest that a name should be globally unique. "globally" is
not sufficiently specific to be unambiguous. If you truly mean that
there is only one anywhere on earth, that's pretty hard to guarantee.
You probably mean within an adminstrative domain, but given multiple
protocols sharing the table, even that might be difficult to pin down.
You'll need to determine just what the requirement is to make this
unambiguous.
7) "An identity can contain multiple names, addresses, and
credentials." is ambiguous. Can you describe this in MIB module terms?
How are they separated - different rows, or delimited substrings, or
... ?
8) I suspect the area directors won't like your COMPILE hint; it
stands too much chance of somebody releasing product using that
unassigned OID.
9) ipsAuthInstDescr - in a master/subagent implementation, I'm not
sure the subagents know if they are the only instance; who would
determine there was only one instance? If a zero-length string is
used, how does one reference the instance by name (see #5)?

I figure that's enough to start with ;-)
Hope it's helpful

David Harrington
[email-masked]
co-chair IETF SNMPv3 WG, concluded

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips