Network Working Group Steven M. Bellovin
Internet Draft AT&T Labs Research
Expiration Date: May 1998 November 1997
Report of the IAB Security Architecture Workshop
draft-iab-secwks-report-00.txt
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. 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. 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
Bellovin [Page 1]
Internet Draft draft-iab-secwks-report-00.txt November 1997
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.
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.
4. 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.
5. 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
Bellovin [Page 2]
Internet Draft draft-iab-secwks-report-00.txt November 1997
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?
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.
6. 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.
Bellovin [Page 3]
Internet Draft draft-iab-secwks-report-00.txt November 1997
7. 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
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.
8. 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 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 should 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)
Bellovin [Page 4]
Internet Draft draft-iab-secwks-report-00.txt November 1997
* 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")
9. 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 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
Bellovin [Page 5]
Internet Draft draft-iab-secwks-report-00.txt November 1997
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.
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 [mossrfc].
One security mechanism was deemed to be unacceptable: plaintext
passwords. That is, no protocol that relies on passwords sent over
unencrypted channels is acceptable.
10. 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 -- DNSsec -- but
we need a more general scheme. One special case is email, where the
previous IETF standard (PEM) has failed in the marketplace. Finally,
we need a way to secure the routing system. This task is complex
because the neither the originator of the route nor the immediate
neighbor of the questioning system have sufficient ability to sign or
validate the route ultimately received.
Bellovin [Page 6]
Internet Draft draft-iab-secwks-report-00.txt November 1997
11. 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.
12. 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 Blakely.
13. References
[RFC 1825] Security Architecture for the Internet Protocol. R.
Atkinson. August 1995.
[RFC 2104] HMAC: Keyed-Hashing for Message Authentication. H.
Krawczyk, M. Bellare, R. Canetti. February 1997.
[ISAKMP drafts]
[RFC 2065] Domain Name System Security Extensions. D. Eastlake,
3rd, C. Kaufman. January 1997.
[RFC 1847] Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N.
Freed.
October 1995.
[TLS draft]
[RFC 1421] Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures. J. Linn.
February 1993.
[RFC 1422] Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management. S. Kent. February 1993.
[RFC 1423] Privacy Enhancement for Internet Electronic Mail: Part
III: Algorithms, Modes, and Identifiers. D. Balenson. February
1993.
[RFC 1424] Privacy Enhancement for Internet Electronic Mail: Part
Bellovin [Page 7]
Internet Draft draft-iab-secwks-report-00.txt November 1997
IV: Key Certification and Related Services. B. Kaliski.
February 1993.
[mossrfc]
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 rgm3@chrysler.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@Eng.Sun.COM
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 [Page 8]
