Browse Prior Art Database

Report of the IAB Security Architecture Workshop (RFC2316)

IP.com Disclosure Number: IPCOM000002882D
Original Publication Date: 1998-Apr-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 9 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Bellovin: AUTHOR

Related Documents

10.17487/RFC2316: DOI

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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 17% of the total text.

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

Processing...
Loading...