rfc2316.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

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.

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

      - 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