Subject: Re: [Ips] IPS Authorization MIB

From: Mark Bakke <[email-masked]>
Date: Tue, 15 Feb 2005 00:04:20 -0600

David-

Thanks for your comments.  I've attempted to address them below, and
I have some questions.  I am about ready to publish the iSCSI MIB that
goes along with this one, and I think that many of your comments will
apply to that one as well.

Mark

David B Harrington wrote:

>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.
>
The Security Considerations section was intended to point out these 
risks.  As far as the
SNMPv3 architecture document, the threats in section 1.4 seem to address 
threats to
the management protocol itself, rather than MIB content.  I assumed that 
the statements
recommending SNMPv3 with authentication and privacy were enough.  I did 
call out
the specific dangers in modifying and/or viewing information from the 
MIB module.

What specifically do you see missing?  From your comment, it appears 
that I should be
addressing the fact that non-SNMP protocols can also view and modify 
this information,
and point out that they need to address the SNMPv3 architecture document 
threats as
well; is that it?

>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. 
>
OK; will fix.

>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.
>
OK; I agree that adding a discussion of contexts would help.  Instances 
and contexts are
meant to be complementary; when instances are used for partitioning, a 
whole "partition"
of the MIB can easily be assigned to a context.

I could add a "Relationship to SNMP Contexts" section as in RFC 2737 
(Entity MIB v2).

>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.
>
This is something I had not yet seen in a MIB; typically the management 
station can't
rely much on index values staying the same.  I'd like to just steal what 
the best practise
is; is there a particular MIB that you think would be appropriate?

>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.
>
I'm not quite sure what to do with this one.

The USM MIB is used to specify access to SNMP itself via SNMPv3 
authentication etc,
right?  The ips-auth MIB is used to specify users of IP storage devices, 
which use an
entirely different set of credentials and authentication protocols.  I 
haven't seen a reference
to the USM mib in other MIBs; what do you have in mind?  Other than the 
fact that since
security-related information is set and retrieved through the ips-auth 
MIB, necessitating
SNMPv3 and USM, is there anything else I need to be saying?

>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?
>
We had quite a few discussions a few years back when we started the 
project on
indexing MIBs by text values.  The thinking at the time was that since 
using integer
indices was much more efficient both on the wire and on the processor, 
that these
were preferred over potentially very long text values as indices, even 
if it meant keeping
a "manufactured" index around.  I still think that this is valid.

We were a bit loose on the requirement for this name to be unique; the same
goes fore ipsAuthIdentDescription.  I think that you are correct that 
these really
should be unique (InstDescr across the agent, and IdentDescription 
across the
instance) and could be formalized a bit more.  I think this would solve 
it, and does
not break anything that we intended to support.

>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.
>
In the iSCSI case (the first MIB to reference this one), an 
ipsAuthIdentName is
equivalent to an iSCSI name, which is, if allocated according to RFCs 
3720-22,
globally unique.  Of course, if another protocol is sharing the table, 
the requirement
for this may be different.

Perhaps it would be better to state that this name must be unique within 
whatever
context (not in the SNMP sense) makes sense for the referencing 
protocol.  That
sounds a bit like a cop-out, but it might solve the problem.

>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
>... ?
>
OK; I can elaborate on that one a bit.

>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.
>
OK; that was primarily there during development of the MIB drafts so we 
could run it
through the compiler without having to add the lines every time.  For 
the final draft, this
will be replaced (hopefully soon) by the actual OID anyway.  I'll delete 
this in the next
rev.

>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)?
>  
>
Good point; I suppose if a subagent provides a zero-length string, the 
master would
have to fill it in with something or reject it.

Is it a common practise for a master agent to do this sort of fix-up?

With a uniqueness requiremetn for the InstDescr, a master agent will 
have to at
least check for uniqueness of these amongst the subagents.

>I figure that's enough to start with ;-)
>  
>
That was plenty, and very helpful.

>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
>
>  
>

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