GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2316

Network Working Group S. Bellovin Request for Comments: 2316 AT&T Labs Research Category: Informational April 1998

          Report of the IAB Security Architecture Workshop

1. Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

2. Copyright Notice

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

3. Abstract

 On 3-5 March 1997, the IAB held a security architecture workshop at
 Bell Labs in Murray Hill, NJ.  We identified the core security
 components of the architecture, and specified several documents that
 need to be written.  Most importantly, we agreed that security was
 not optional, and that it needed to be designed in from the
 beginning.

3.1. Specification Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119.

4. Motivations

 On 3-5 March 1997, the IAB held a security architecture workshop at
 Bell Labs in Murray Hill, NJ.  The ultimate goal was to design a
 security architecture for the Internet.  More concretely, we wished
 to understand what security tools and protocols exist or are being
 developed, where each is useful, and where we are missing adequate
 security tools.  Furthermore, we wanted to provide useful guidance to
 protocol designers.  That is, if we wish to eliminate the phrase
 "security issues are not discussed in this memo" from future RFCs, we
 must provide guidance on acceptable analyses.

Bellovin Informational [Page 1] RFC 2316 Report of the IAB April 1998

 There were twenty-four attendees (their names are listed in Appendix
 A).  Perhaps not surprisingly for such a group, the overwhelming
 majority used some form of cryptography when connecting back to their
 home site from the meeting room.  But the situation on the rest of
 the Internet is not nearly as good; few people use encryption, even
 when they should.
 The problem is that the rate of attacks is increasing.  Apart from
 the usual few elite hackers -- the ones who find the new holes --
 there are many canned exploit scripts around.  ("Click here to attack
 this system.") Furthermore, the attackers have gotten smarter; rather
 than going after random university machines, more and more are
 targeting the Internet infrastructure, such as routers, high-level
 name servers, and the like.
 The problem is compounded by organizational laziness.  Users and
 system administrators want "magic security" -- they want whatever
 they do to be secure, regardless of whether or not it is, or even can
 be.

5. General Philosophy

 We concluded that in general, end-to-end security is better.  Thus,
 one should use something like PGP or S/MIME for email, rather than
 relying on an IPsec layer.  In general, relying on the security of
 the infrastructure is a bad idea; it, too, is under attack.  Even
 firewall-protected intranets can be subverted.  At best, the
 infrastructure should provide availability; it is the responsibility
 of individual protocols not to make unreasonable demands on the
 infrastructure during an attack.

6. IETF Structure

 Our security problem is compounded by the IETF's inherent structure
 (or, in some cases, the lack thereof).  By intent, we are a volunteer
 organization.  Who should do the security work?  The other protocol
 designers?  Often, they have neither the time nor the interest nor
 the training to do it.  Security area members?  What if they are not
 interested in some subject area, or lack the time themselves?  We
 cannot order them to serve.
 To the extent that the IETF does have management, it is embodied in
 the working group charters.  These are in essence contracts between
 the IESG and a working group, spelling out what is to be done and on
 what schedule.  Can the IESG unilaterally impose new requirements on
 existing working groups?  What if security cannot be added on without
 substantial changes to the fundamental structure of a protocol that
 has been reworked over several years?

Bellovin Informational [Page 2] RFC 2316 Report of the IAB April 1998

 Finally, there is a perception problem:  that IPsec will somehow
 solve the security problem.  It won't; indeed, it can't.  IPsec
 provides excellent protection of packets in transit.  But it's hard
 to deploy on individual hosts, does not protect objects that may be
 retransmitted (i.e., email messages), does not address authorization
 issues, cannot block against excess resource consumption, etc.

7. Documents to be Written

 Collectively, we decided on several documents that need to be
 written:
    Taxonomy of Attacks
       In order to defend a protocol against attacks, one must, of
       course, know the kinds of attacks that are possible.  While the
       specifics differ from protocol to protocol, a number of general
       categories can be constructed.
    Implementation Hints and Pitfalls
       Even if a protocol is sound, a host running it can be
       vulnerable if the protocol is implemented improperly.  A
       variety of common errors can and do subvert the best designs.
    Firewall Issues
       Firewalls are both a common defense and a much-reviled wart on
       the Internet.  Regardless, they are unlikely to go away any
       time soon.  They have both strengths and weaknesses that must
       be considered when deploying them.  Furthermore, some protocols
       have characteristics that are unnecessarily firewall-hostile;
       such practices should be avoided.
    Workshop Report
       This document.

8. Working Group Charters

 The actual text in the working group charter is likely to be
 something fairly simple, like
    Protocols developed by this working group will be analyzed for
    potential sources of security breach. Identified threats will be
    removed from the protocol if possible, and documented and guarded
    against in other cases.
 The actual charter text represents a policy enjoined and enforced by
 the IESG, and may change from time to time and from charter to

Bellovin Informational [Page 3] RFC 2316 Report of the IAB April 1998

 charter. However, it essentially references and asks for text in
 documents conforming to the following, which may be very appropriate
 to include in the RFC.

9. Guidelines on writing Security Considerations in an RFC

 A "threat" is, by definition, a vulnerability available to a
 motivated and capable adversary. CERT advisories are quite
 predictable given a knowledge of the target of the threat; they
 therefore represent an existence proof, but not a threat analysis.
 The point is to determine what attacks are possible ("capabilities"
 of a potential attacker) and formulate a defense against the attacks,
 or convincingly argue that the attack is not realistic in some
 environment and restrict use of the protocol to that environment.
 Recommended guidelines:
    All RFCs - MUST meaningfully address security in the protocol or
    procedure it specifies. It MUST consider that it is giving its
    data to "the enemy" and asking it to be delivered to its friends
    and used in the manner it intended. Consideration MUST be given to
    the ramifications of the inherent danger of the situation.
  1. MUST do "due diligence" to list the threats to which the

protocol is vulnerable. Use of legal term does not imply legal

    liability, but rather the level of responsibility expected to be
    applied to the analysis. This discussion might occur throughout
    the document or in the Security Considerations section; if it
    occurs throughout, it MUST be summarized and referenced in the
    Security Considerations section.
  1. MUST discuss which of those threats are
    • Ameliorated by protocol mechanisms (example: SYN attack is

ameliorated by clever code that drops sessions randomly when

       under SYN attack)
  • Ameliorated by reliance on external mechanisms (example: TCP

data confidentiality provided by IPSEC ESP)

  • Irrelevant ("In most cases, MIBs are not themselves security

risks; If SNMP Security is operating as intended, the use of a

       MIB to change the configuration of a system is a tool, not a
       threat. For a threat analysis of SNMP Security, see RFC ZZZZ.")
  • Not addressed by the protocol; results in applicability

statement. ("This protocol should not be used in an

       environment subject to this attack")

Bellovin Informational [Page 4] RFC 2316 Report of the IAB April 1998

10. Core Security Mechanisms

 A variety of security mechanisms exist today.  Not all are well-
 designed; not all are suitable for all purposes.  The members of the
 workshop designated a number of protocols as "core".  Such protocols
 should be used preferentially, if one of them has properties that
 match the needs of your protocol.  The following were designated as
 core:
    IPsec [RFC 1825] is the basic host-to-host security mechanism.  It
       is appropriate for use any time address-based protection would
       have been used, including with such programs as rsh and rlogin.
       If and when platforms support user-based keying, this scope may
       be expanded.
       One particular technique used by IPsec, HMAC [RFC 2104], is
       more generally useful.  If cryptographic authentication but not
       secrecy is needed, and IPsec is not applicable, HMAC should be
       used.
    ISAKMP/Oakley [ISAKMP drafts] is the basic key negotiation
       protocol for IPsec.  As such, it should be deployed when IPsec
       is used.  With the appropriate "domain of interpretation"
       document, it should be used to negotiate pairwise keys for
       other protocols.
    DNSsec [RFC 2065] is not only crucial for protecting the DNS --
       cache contamination is the easiest way to launch active attacks
       -- it's also needed in many situations when IPsec is used.
    Security/Multipart [RFC 1847] is the preferred way to add secured
       sections to MIME-encapsulated email.
    Signed keys in the DNS.  There is, as noted, widespread agreement
       that DNS records themselves must be protected.  There was less
       agreement that the key records should be signed themselves,
       making them in effect certificates.  Still, this is one
       promising avenue for Internet certificates.
    X.509v3 is the other obvious choice for a certificate
       infrastructure.  Again, though, there was no strong consensus
       on this point.
    TLS [TLS draft] was seen by some as the preferred choice for
       transport-layer security, though there was no consensus on this
       point.  TLS is less intrusive to the operating system than
       IPsec; additionally, it is easier to provide fine-grained
       protection this way.

Bellovin Informational [Page 5] RFC 2316 Report of the IAB April 1998

 Some protocols were designated as "useful but not core".  These were
 insufficiently general, too new, or were substantially duplicative of
 core protocols.  These include AFT/SOCKS, RADIUS, firewalls, GSS-API,
 PGP, Kerberos, PGP-MIME, PKIX-3, the various forms of per-hop
 authentication (OSPF, RSVP, RIPv2), *POP, OTP, S/MIME, SSH, PFKey,
 IPsec API, SASL, and CRAM/CHAP.  Obviously, entries on this list may
 move in either direction.
 A few protocols were considered "not useful".  Primarily, these are
 ones that have failed to catch on, even though they've been available
 for some time.  These include PEM [RFC 1421, 1422, 1423, 1424] and
 MOSS [RFC 1848].  (The phrase "not useful" does not imply that they
 are incorrect, or are lacking in important information.  However,
 they do not describe protocols that we are currently encouraging the
 use of.)
 One security mechanism was deemed to be unacceptable:  plaintext
 passwords.  That is, no protocol that relies on passwords sent over
 unencrypted channels is acceptable.

11. Missing Pieces

 Participants in the workshop identified three significant missing
 pieces: object security, secure email, and route security.
 Object security refers to protection for individual data objects,
 independent of transport.  We have one such already -- Secure DNS --
 but we need a me general scheme.  MIME is a candidate object
 framework, in part because it is the core of the two most widely used
 and deployed applications: the web and email.  However, securing
 email has been problematic and the web is not that far in front.
 Secure email is a critical need and has been for some time.  Two
 attempts to standardize secure email protocols (PEM and MOSS) have
 failed to be accepted by the community, while a third protocol (PGP)
 has become a de facto standard around the world.  A fourth protocol,
 an industry standard (S/MIME), has been gaining popularity.  Both of
 these latter of entered the Internet standards process.
 Route security has recently become a critical need.  The
 sophistication of the attackers is on the rise and the availability
 of attacking toolkits has increased the number of sophisticated
 attacks.  This task is especially complex because the requirement for
 maximum performance conflicts with the goal of adding security, which
 usurps resources that would otherwise enhance the performance of the
 router.

Bellovin Informational [Page 6] RFC 2316 Report of the IAB April 1998

12. Security Considerations

 Security is not and cannot be a cookie cutter process.  There is no
 magic pixie dust that can be sprinkled over a protocol to make it
 secure.  Each protocol must be analyzed individually to determine
 what vulnerabilities exist, what risks they may lead to, what
 palliative measures can be taken, and what the residual risks are.

13. Acknowledgments

 This RFC is largely based on the minutes compiled by Thomas Narten,
 whose work in turn was partly based on notes by Erik Huizer, John
 Richardson, and Bob Blakley.

14. References

    [RFC 1825] Atkinson, R., "Security Architecture for the Internet
       Protocol", RFC 1825, August 1995.
    [RFC 2104] Krawcyzk, H., Bellare, M., and R. Canett, "HMAC:
       Keyed-Hashing for Message Authentication", RFC 2104, February
       1997.
    [ISAKMP drafts] Works in Progress.
    [RFC 2065] Eastlake, D., and C. Kaufman, "Domain Name System
       Security Extensions", RFC 2065, January 1997.
    [RFC 1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
       "Security Multiparts for MIME: Multipart/Signed and
       Multipart/Encrypted", RFC 1847, October 1995.
    [TLS draft] Dierks, T., and C. Allen, "The TLS Protocol Version
       1.0", Work in Progress.
    [RFC 1421] Linn, J., "Privacy Enhancement for Internet Electronic
       Mail: Part I: Message Encryption and Authentication
       Procedures", RFC 1421, February 1993.
    [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
       Mail: Part II: Certificate-Based Key Management", RFC 1422,
       February 1993.
    [RFC 1423] Balenson, D., "Privacy Enhancement for Internet
       Electronic Mail: Part III: Algorithms, Modes, and Identifiers",
       RFC 1423, February 1993.

Bellovin Informational [Page 7] RFC 2316 Report of the IAB April 1998

    [RFC 1424] Kaliski, B. "Privacy Enhancement for Internet
       Electronic Mail: Part IV: Key Certification and Related
       Services", RFC 1424, February 1993.
    [RFC 1848] Crocker, S., Freed, N., Galvin, J. and S. Murphy, "MIME
       Object Security Services", RFC 1848, October 1995.

Appendix A. Attendees

   Ran Atkinson      rja@inet.org
   Fred Baker        fred@cisco.com
   Steve Bellovin    bellovin@acm.org
   Bob Blakley       blakley@vnet.ibm.com
   Matt Blaze        mab@research.att.com
   Brian Carpenter   brian@hursley.ibm.com
   Jim Ellis         jte@cert.org
   James Galvin      galvin@commerce.net
   Tim Howes         howes@netscape.com
   Erik Huizer       Erik.Huizer@sec.nl
   Charlie Kaufman   charlie_kaufman@iris.com
   Steve Kent        kent@bbn.com
   Paul Krumviede    paul@mci.net
   Marcus Leech      mleech@nortel.ca
   Perry Metzger     perry@piermont.com
   Keith Moore       moore@cs.utk.edu
   Robert Moskowitz  rgm@htt-consult.com
   John Myers        jgm@CMU.EDU
   Thomas Narten     narten@raleigh.ibm.com
   Radia Perlman     radia.perlman@sun.com
   John Richardson   jwr@ibeam.jf.intel.com
   Allyn Romanow     allyn@mci.net
   Jeff Schiller     jis@mit.edu
   Ted T'So          tytso@mit.edu

Appendix B. Author Information

 Steven M. Bellovin
 AT&T Labs Research
 180 Park Avenue
 Florham Park, NJ  07932
 USA
 Phone: (973) 360-8656
 EMail: bellovin@acm.org

Bellovin Informational [Page 8] RFC 2316 Report of the IAB April 1998

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Bellovin Informational [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2316.txt · Last modified: 1998/04/10 21:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki