1 / 6

The need for better security considerations guidance

The need for better security considerations guidance. Dan Romascanu (with Contributions from Andy Bierman and Pasi Eronen) IETF meeting Montreal, July 2006. Scope. Need for more clear and detailed guidelines for security sections in protocol documents Discussed at the IESG retreat in May

jmcgruder
Download Presentation

The need for better security considerations guidance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The need for better security considerations guidance Dan Romascanu (with Contributions from Andy Bierman and Pasi Eronen) IETF meeting Montreal, July 2006

  2. Scope • Need for more clear and detailed guidelines for security sections in protocol documents • Discussed at the IESG retreat in May • What is the range of applicability of BCP 61 (RFC 3365)? • What's wrong with BCP 72 (RFC 3552)? • Some ideas for improvement

  3. Is anything wrong? • About 35% of the DISCUSSes in the IESG documents review are security-oriented • based on Bill Fenner’s statistics and direct observation of the IESG meetings • many of them seem to be pretty fundamental, reflecting a gap between the level of understanding of the security requirements between protocol designers and security experts • They come very late in the process, especially if security reviews were not performed in the document prior the discussion in the IESG • Lack of consensus and consistency among security advisors • Especially when it comes to applying the latest standards which may be work-in-progress • RESULT • Frustrating last-minute delays in getting protocol documents approved • Lack of determinism in assessing how far a document is from completion • Perception that security is ‘black magic’ – cannot be solved in a rational manner, better try to finesse • Eventually – either ‘secure and late’ or ‘non-secure’ documents, and a lot of frustration and incertitude

  4. What is the range of applicability of BCP 61 (RFC 3365)? • RFC 3365 - Strong Security Requirements for Internet Engineering Task Force Standard Protocols • The principal problem is that RFC 3365 is too ‘high level’ • E.g. – I do not know what to do with: • Yet we often require cryptographic technology to implement authentication and integrity of protocol messages. So if the question is "MUST we implement confidentiality?" the answer will be "depends". However if the question is "MUST we make use of cryptographic technology?" the answer is "likely". • It really needs some implementation notes • Including some sort of table to help a WG figure out which security feature requirements match which protocols to use

  5. What's wrong with BCP 72 (RFC 3552)? • RFC 3552 - Guidelines for Writing RFC Text on Security Considerations • Timeliness • A large number of references are obsoleted and updated • RFC2402 obsoleted by 4302, 4305 • RFC2535 is obsoleted by RFC4033, RFC4034, RFC4035, Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445, RFC3597, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845 • 2406 is Obsoleted by RFC4303, etc., etc. • (not to speak about work-in-progress – e.g. 4346 and 4366 was referred in security reviews months before publication) • over-emphasizes communications security. While the "Internet threat model" (bad guys in the network between two-or-more honest parties) in Section 3 is of course very traditional for cryptographic protocols (like IPsec and TLS), it maybe outright misleading for most IETF protocols. • example: in RFC 4072 (Diameter EAP Application) security considerations section, the communication security threats are dealt with a single paragraph. The rest of the five _pages_ deals with threats arising from authenticated Diameter peers. • Section 5 - Writing Security Considerations Sections is extremely ‘thin’ • It is already thin wrt. Sections 3 (Internet Threat model) and Section 4 (common issues – actually requirements) and does not help a document author understand what is expected • Not everything fits into a Security Considerations section • Security needs to be embedded in the design of the protocol • Extended security sections or separate documents (e.g. RFC 4261)

  6. Some ideas for improvement • Update RFC 3552 • Create a ‘living’ Web version that can be updated permanently to reflect later security documents • Try to catch things earlier • Enforce mandatory security reviews prior to the IESG review for any new protocol document • early review process • Increase the level of determinism by better documenting the security requirements • A guidelines document about how to perform security reviews which could be used by the document authors to understand what they would expect • Crafted on the example of what RFC 4181 is for MIB reviewers and MIB documents authors • Adapt security requirements to the scope of the protocol • Routing, signaling, provisioning, monitoring – each have different needs • Better educational materials • Revise EDU security material so that much more information is provided about • when and how does strong security apply? • ‘how to design security into protocols’? - today’s ‘Security Considerations Considerations’ section does not even mention RFC 3552!

More Related