[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: guidelines section 3.6 (security considerations)



Title: RE: guidelines section 3.6 (security considerations)
What I proposed a month ago was larger in scope than this proposal.
 
The current proposal is about giving some guidance to mib writers beyond "write a detailed security considerations section" and reviewer guidelines beyond "make sure it is detailed."
 
If you really want to push this off to a new document, I will volunteer to help write the document.
 
dbh
 
 -----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, February 06, 2003 7:02 PM
To: Harrington, David; Mreview (E-mail)
Subject: RE: guidelines section 3.6 (security considerations)

David, I think you brought this up a month or so ago as
well. I agree that that is usefull work and guidelines to
do. But I think they are out of scope of the MIB reviewers
guidelines.

When we composed the new security guidelines, the security
ADs would like much more extensive stuff too. I suggested
it could possibly put in the draft-iab-sec-cons-02.txt
document... but they did not want to slow that down.
So they agreed that we should do a separate MIB and/or SNMP
security considerations document. ANd that seems exactly the
type of stuff that you are talking about.

Do you volunteer?

Once we have that document, it may be possible to extract
a few simple guidelines (with ptrs to that new doc) about
what to do in the security and VACM arena that you talk
about.

Thanks,
Bert

> -----Original Message-----
> From: Harrington, David [mailto:dbh@enterasys.com]
> Sent: donderdag 6 februari 2003 20:08
> To: C. M. Heard; Mreview (E-mail)
> Subject: RE: guidelines section 3.6 (security considerations)
>
>
> Hi,
>
> I agree items 1 and 2 could be pout into the mib-security
> guidelines. I think it would be a good place for this.
>
> I think item #3 and the fourth item (#5 - whoops!) could also
> be documented there, and the reviewer guidelines could
> recommend checking for these points.
>
> The fifth item (#4) would require a separate document to
> define the approach and the syntax.
>
> dbh
>
> > -----Original Message-----
> > From: C. M. Heard [mailto:heard@pobox.com]
> > Sent: Thursday, February 06, 2003 1:51 PM
> > To: Mreview (E-mail)
> > Subject: RE: guidelines section 3.6 (security considerations)
> >
> >
> > On Thu, 6 Feb 2003, Harrington, David wrote:
> > > As representative of a vendor trying to write mibs and also to
> > > tie the sensitivity of mib objects to VACM views, I would like
> > > to see something more useful from the IETF than requiring mib
> > > writers to provide a list of objects in a security
> > > considerations section.
> > >
> > > I think we should:
> > > 1) develop quick guidelines for categorizing security sensitivity,
> > > 2) develop quick guidelines for categorizing network
> > stability sensitivity,
> > > 3) have writers describe sensitivity in the mibs proper,
> > > 5) recommend a mib organization strategy to make mibs
> > >    security-control-friendly, and
> > > 4) have writers categorize objects in a standardized
> > machine-readable
> > >    format.
> >
> > Be aware that I can't do all these things.  If indeed all this
> > information needs to go in the guidelines document, then we will
> > need another volunteer to draft most the text.  Please understand
> > that I'm not trying to be uncooperative by saying this;  the problem
> > is that I'm just not qualified to do such a task.  I lack the
> > knowledge of security issues (and of the workings of VACM) that
> > would be needed to do a competent job.
> >
> > Once concern that I have about putting all of this stuff into the
> > guidelines document is that it would dramatically increase the scope
> > of the project.  I have avoided discussing general MIB design issues
> > such as those covered in <draft-ietf-snmpconf-bcp-12.txt> precisely
> > to limit the scope.  Some of the things you are suggesting seem to
> > be issues of that nature, and maybe it would be better to have a
> > separate document to deal with them.  There is of course a middle
> > ground, e.g., items (1) and (2) are not that big and could probably
> > be included without too much pain, although the right place for them
> > might be in http://www.ops.ietf.org/mib-security
> >
> > //cmh
> >
> >
> >
> >
>