Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
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: 2000-Sep-13
Document File: 8 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Bellovin: AUTHOR

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 text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 15% 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.

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