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.