Internet Architecture Board


IAB Minutes 1997-04-09

Home»Documents»Minutes»Minutes 1997»IAB Minutes 1997-04-09

Minutes of the Open Internet Architecture Board (IAB)

Reported by: Abel Weinrib,

Jon Postel, RFC Editor, reported that the backlog of RFCs waiting for publication has been significantly reduced over the past few months. He was applauded for this progress.

Steve Bellovin reported on the IAB security architecture workshop. See associated slides.

Comments/questions from the floor:

    Authenticode is a problem — it encourages inexpert programmers to write programs that can be scripted by a hacker. Steve Bellovin: Yes, any sort of mobile code is a serious problem.

    Jim Bound: Please make the slides publicly available. Steve Bellovin: Yes, they will be up on Steve Bellovin’s Web page and part of the minutes of this meeting.

    Merging of network management and operations areas is somewhat difficult; people from the two communities have quite different approaches, perspectives and viewpoints. Fred Baker: The intention of the reorganization is to make sure the tools that come out of the management area are useful to those who are responsible for day-to-day operations of networks.

    Steve Knowles: I’ve seen IAB retreats come and go… What is the IAB going to do with the results of this retreat? Why not reject all protocols that don’t meet security requirements? Fred Baker: Yes, once the proper documents are in place, working groups will be required to seriously address security. Need the community as a whole to support this, even if the protocol has been under development for years, is already deployed, etc. “The community is on notice.”

    Dave Crocker: Working groups need help from early on. Currently, we have each working group trying to define its own solutions.

    Bob Hinden: We need a deployed, ubiquitous infrastructure (keys, etc.)– only then will we learn how to use it. Security in IETF specs is only a beginning.

Slides – Bellovin

    Public Report on Secret Meeting About Keeping Secrets

      Steven M. Bellovin


      Ran Atkinson
      Fred Baker
      Setven Bellovin
      Bob Blakley
      Matt Blaze
      Brian Carpenter
      Jim Ellis
      James Galvin
      Tim Howes
      Erik Huizer
      Charlie Kaufman
      Steve Kent
      Paul Krumviede
      Marcus Leech
      Perry Metzger
      Keith Moore
      Robert Moskowitz
      John Meyers
      Thomas Narten
      Radia Perlman
      John Richardson
      Allyn Romanow
      Jeff Schiller
      Ted T’So

    Possible Desired Outcomes

    • Dependency graph of protocols and security mechanisms. WHat are the “holes”? The duplications?
    • Finite set of concrete recommendations
    • Guidelines on how to write a good “security considerations” section. Even security protocols need to document their uses andlimitations

    Break-in Trends (Jim Ellis)

    • More use of encryption by hackers
    • User-friendly exploitation scripts
    • Increasing number of attacks on the network infrastructure
    • Repeated use of old vulnerabilities
    • Source not needed for attacks

    IETF Issues (Jeff Schiller)

    • Do we choose architectural purity or let people do their own thing
    • IPSec doesn;t solve all problems
    • The IETF is made of volunteers, how do we manage the process?
    • Who does security work? The WGs? The security area?
    • What about long-running WGs? How can security be incorporated into their output?
    • Hippocratic Oath: First do no harm.

    Documents Being Written

    • New text for Working Group charters
    • Guidelines for “security considerations” section
    • Taxonomy of attacks
    • Implementation hints and pitfalls
    • Firewall issues
    • workshop report

    Security Considerations

    • Document the risks (what can be attacked though this mechanism?)
    • Document the assumptions (topology, deployment model, etc)
    • If appropriate, recommend the use of particular security technologies

    WG Charters

    • All WGs must address security
    • This will include existing working groups, during charter updates
    • Each WG will work with “security volunteers”
    • No “security will be added later”

    General Assumptions

    • End-to-end security is generally better
    • The infrastructure is subject to attacks
    • Even intranets cannot be presumed secure against eavesdroppers
    • The infrastructure, and not individual protocols, has to provide availability, but protocols shouldn’t make this worse under attack

    Taxonomy; Hints

    • What kinds of things do hackers do?
    • What are their targets?
    • How to avoid common errors (a la RFC 1750)?
    • What are the global risks>


    • What can they do? What can;t they do?
    • When are they useful or not>
    • What protocol characteristics are firewall-friendly? Firewall-hostile?

    Categorization of Security Tools

    • Core — we must have it, should be used if appropriate
    • Useful, but not core
    • Not widely regarded as useful
    • To be killed
    • Out of scope


    • DNSsec
    • IPsec
    • ISAKMP/Oakley
    • Security Multipart
    • Signed keys in the DNS (50% support)
    • X.509v3 (50% support)
    • TLS (some support)

    Useful But Not Core

      Many other security protocols are useful, but not central. This does not mean that can’t be used.

    Not Widely Regarded as Useful

      Protocols in this category include those that have been superseded, or that have failed to catch on, such as PEM and MOSS, or those that are duplicative of other work.

    To be Killed: Plaintext Passwords

      Any protocol that relies on the transmission of unencrypted passwords in terminally broken

      Any protocol that puts confidential information in public palces (such as URLs) is similarly broken

    Out of Scope


    Missing Pieces

    • Object Security
    • Secure e-mail
    • Security for external routes

    Security Issues are not addressed in this memo

An online copy of these and other minutes are available at http// Also, visit the IAB Web page at