Subject: Security guidelines discussion in the IESG

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 26 Apr 2006 14:30:50 +0300

The IESG retreat meeting (first week of May) includes an agenda item
concerning better documented guidelines for security sections and
reviews in protocol documents.
 
---------------------
 
7. Security guidelines (1 hour)
 - Need for more clear and detailed guidelines for security 
   sections in protocol documents.
 - What is the range of applicability of BCP 61 (RFC 3365)?
 - What's wrong with BCP 72 (RFC 3552)?
 - What internal education is needed?
 
  Dan to lead as the customer for this; he will work with
  Sam and Russ to prepare
-----------------------

This was triggered by the experience that we had with the raqmon set of
documents in the RMONMIB WG, where we had at hand no security guidelines
document to provide us a reference for what we need to do, and the
security review came at a very late stage and re-opened to a large
extend the whole set of documents. 
 
An initial set of questions that come to my mind:
 
- how to write a security threats model
- how the security threads need to be matched by security
counter-measures
- what references apply and need to be referred
- when is a security section enough, when are separate security
requirements and mapping documents needed
- when is a security advisor needed 
- how do we deal with the evolution of the security protocols
 
My instinct is to say that the security area need to issue a document
similar to what RFC 4181is for MIB reviewers. The security folks seem to
believe that this role is played by RFC 3552, and that the security
advisors for specific WGs would do the rest. In reality for raqmon this
did not work, and maybe other similar cases exist. 
 
We would welcome input to help and document this discussion.
 
Thanks and Regards,
 
Dan

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 26 Apr 2006 09:14:10 -0400

> did not work, and maybe other similar cases exist. 
Dan, could you give more detail on what's wrong with 3552?  As you say, we
thought that 3552 was filling that role.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb