Internet Architecture Board

RFC2850

Public Report on Secret Meeting About Keeping Secrets

Home»Documents»IAB Correspondence, Reports, and Selected Documents»1997»Public Report on Secret Meeting About Keeping Secrets
Public Report on Secret Meeting About Keeping Secrets
March 3-5, 1997
Murray Hill, NJ
Steven M. Bellovin
smb@research.att.com

973-360-8656
AT&T Labs Research Florham Park, NJ 07932
  • Attendees
  • Possible Desired Outcomes
  • Break-in Trends (Jim Ellis)
  • IETF Issues (Jeff Schiller)
  • Documents Being Written
  • Security Considerations
  • WG Charters
  • General Assumptions
  • Taxonomy; Hints
  • Firewalls
  • Categorization of Security Tools
  • Core
  • Useful But Not Core
  • Not Widely Regarded as Useful
  • To be Killed: Plaintext Passwords
  • Out of Scope
  • Missing Pieces
    Top

    Attendees

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

    Top

    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 and limitations.

    Top

    Break-in Trends (Jim Ellis)

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

    Top

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

    Top

    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.

    Top

    Security Considerations

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

    Top

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

    Top

    General Assumptions

    • End-to-end security is usually 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 when under attack.

    Top

    Taxonomy; Hints

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

    Top

    Firewalls

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

    Top

    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.

    Top

    Core

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

    Top

    Useful But Not Core

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

    Top

    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.

    Top

    To be Killed: Plaintext Passwords

    Any protocol that relies on the transmission of unencrypted passwords is terminally broken. Any protocol that puts confidential information in public places (such as URLs) is similarly broken.

    Top

    Out of Scope

    CIFS, DFS, NFS, ONC RPC, LDAP

    Top

    Missing Pieces

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

    Top