attacks are getting better.
Finally, it should noted that the principle of least privilege, which
was mentioned above, may be in contradiction to the principle of
least cost.
7.1 Suggested Short-Term Actions
The general recommendation for short-term Internet security policy
was that the IETF should make a list of desirable short-term
actions and then reach out to work with other organizations to
carry them out. Other organizations include regionals, which may
be in a good position to provide site security counseling services
to their customers, vendors and other providers, and other
societies. We should also give input to the US government to
influence their posture on security in the direction desired by
the community.
A suggested preliminary list of short-term actions was developed.
o Perform external diagnostic security probes
Organizations should be encouraged to use CRACK and other
tools to check the robustness of their own passwords. It
would also be useful to run a variety of security probes from
outside. Since this is a very sensitive issue, some care
needs to be taken to get the proper auspices for such
probing.
Useful probe tools include:
ISS: Klaus (GA)
SATAN: Farmer Venema
ICEPICK: NRL
o Determine Security-Risk Publication Channels
What channels should be used for disseminating information of
security risks?
o Encourage use of one-time passwords.
Available packages: S/Key, SecurID, Enigma, Digital Pathways.
o Develop and publish guidelines for protocol developers, for
security-friendliness and firewall-friendliness.
o Control topology to isolate threats
o Set privacy policy:
* Always
* As much as possible
o Bring Site Security Handbook up to date
o Support use of Kerberos
The subject of the "Clipper chip" came up several times, but there
was not sufficient discussion of this very complex issue for this
grouip to reach a recommendation. It has been observed that there
are a number of quite differing viewpoints about Clipper.
o Some people accept the government's Clipper proposal,
including key escrow by the US government and the
requirement that encryption be in hardware.
o Some people don't mind key escrow by the government in
principle, but the object to the hardware requirement.
o Some people don't mind key escrow in principle, but
don't want the government to hold the keys. They would
be comfortable with having the organization which owns
the data hold the keys.
o Some people don't want key escrow at all.
o Some people don't mind the hardware or the key escrow,
but they don't think this will be acceptable to other
countries and thus will not work internationally.
This report takes no position on any of these viewpoints.
7.2 Suggested Medium-Term Actions
These actions require some protocol design or modification;
however, they use existing security technology and require no
research.
o Authentication Protocol
There is a problem of the choice of technology. Public key
technology is generally deemed superior, but it is patented
and can also induce relatively long computations. Symmetric
key technology (Needham-Schroeder algorithm, as used in
Kerberos) has some technical drawbacks but it is not
patented. A system based on symmetric keys and used only for
authentication would be freely exportable without being
subject to patents.
o Push Kerberos
Engineering is needed on Kerberos to allow it to interoperate
with mechanisms that use public key cryptography.
o Push PEM/RIPEM/PGP...
o Develop an authenticated DNS
o Develop a key management mechanism
o Set up a certificate server infrastructure
Possible server mechanisms include the DNS, Finger, SNMP,
Email, Web, and FTP.
o Engineer authentication for the Web
7.3 Suggested Long-Term Actions
In this category, we have situations where a threat has been
identified and solutions are imaginable, but closure has not been
reached on the principles.
o Executable Apps
o Router sabotage counter-measures
o Prevent Byzantine routing.
o Proxy Computing
o Decomposition of computers
o Are there "good" viruses?
APPENDIX A -- Workshop Organization
The following list of attendees indicates also the breakout group to
which they were assigned.
Breakout Groups
Group I.1 Leader:
1 Christian Huitema, INRIA (IAB)
1 Steve Bellovin, AT&T
1 Bob Braden, ISI (IAB)
1 John Curran, NEARNET
1 Phill Gross, ANS (IETF/IAB)
1 Stev Knowles, FTP Software (Internet AD)
1 Barry Leiner, USRA (IAB)
1 Paul Mockapetris, ISI
1 Yakov Rekhter, IBM (IAB)
1 Dave Sincoskie, Bellcore (IAB)
Group I.2 Leader:
2 Steve Crocker, TIS (Security AD)
2 Jon Crowcroft
2 Steve Deering, PARC
2 Paul Francis, NTT
2 Van Jacobson, LBL
2 Phil Karn, Qualcomm
2 Allison Mankin, NRL (Transport AD, IPng AD)
2 Radia Perlman, Novell
2 John Romkey, ELF (IAB)
2 Mike StJohns, ARPA (IAB)
Group I.3 Leader:
3 Dave Clark, MIT
3 Deborah Estrin, USC
3 Elise Gerich, Merit (IAB)
3 Steve Kent, BBN (IAB)
3 Tony Lauck, DEC (IAB)
3 Tony Li, CISCO
3 Bob Hinden, Sun (IESG->IAB liaison, Routing AD)
3 Jun Murai, WIDE (IAB)
3 Scott Shenker, PARC
3 Abel Weinrib, Bellcore
The following were able to attend only the third day, due to a
conflicting ISOC Board of Trustees meeting:
Scott Bradner, Harvard (IPng AD)
Jon Postel, ISI (IAB)
The workshop agenda was as follows.
Tues Feb 8
9:00 - 10:30 Plenary
Discuss facilities, meeting goals, agenda, organization.
Establish some minimal common understandings. Assign
scenarios to Breakout I groups.
10:30 - 13:00 Breakout I meetings
Each breakout group examine one or more scenarios and
formulate a list of design questions. Lunch available on
11th floor.
13:00 - 15:00 Plenary
Report, discuss. Collate and shorten list of design
issues. Organize Breakout II groups to work on these
issues.
15:00 - 17:30 Breakout IIa meetings
Work on design issues.
Wed Feb 9
9:00 - 10:00 Plenary
Report, discuss.
10:00 - 13:30 Breakout IIb meetings
More work on design questions, develop list of
requirements.
13:30 - 14:30 Plenary
Report, discuss.
15:30 - 17:30 Breakout III groups
Thurs Feb 10
9:00 - 9:30 Plenary
9:30 - 11:00 Breakout Groups (wrapup)
11:00 - 12:00 Plenary
Discuss possible short-term security recommendations
13:00 - 14:00 Plenary -- Discuss short-term security issues
14:00 - 14:30 Plenary -- Presentation by Steve Bellovin
14:30 - 16:00 Plenary -- Long- and Medium-term
Recommendations
The following scenarios were used as a starting point for
discussions. It distinguished security-S (security as a service to
the end systems) from security-M, security as a mechanism to support
other services. The workshop was intended to be primarily concerned
with interactions among the following different *services*:
o Security-S
o Routing
o Multi-destination delivery (mcast-S)
o Realtime Packet scheduling (realtime)
o Mobility
o Accounting
(and maybe large-scale?)
These categories were then applied to the following scenarios:
S1. Support a private teleconference among mobile hosts connected to
the Internet. [Security-S, mcast-S, realtime, mobility]
S2. The group in S1 is 1/3 the Internet, i.e., there are VERY severe
scaling problems. [Security-S, mcast-S, realtime, mobility,
large-scale]
S3. Charge for communication to support a video teleconference.
[Accounting, realtime, mcast-S]
S4. I am travelling with my laptop. I tune in to radio channel IP-
RADIO, pick-up the beacon and start using it. Who gets the
bill? Why do they believe this is me? Is "me" a piece of
hardware (IP address) or a certified user (PEM certificate)?
[Mobility, accounting (, realtime, mcast-S)]
S5. A Politically Important Person will mcast an Internet
presentation, without danger of interruptions from the audience.
S6. The travel industry wants to use Internet to deliver tickets to
customer premises directly in a secure way, but the customer has
only dial-up capability. [Security-S, mobility]
S7. I am traveling with my laptop and this friendly host is running
the autoconfiguration protocol. I immediately get an address as
"mac1.friendly.host.com". (What is the difference between my
laptop and a bona fide autoconfigured local station?)
[Security-S, mobility]
S8. Multiple people are connected to a subnetwork providing mobility
(e.g., cellular, packet radio). The subnetwork is connected to
multiple places in the "fixed" backbone. How can routing be done
efficiently? [Routing, mobility]
The following scenarios that were suggested do not fit into the
primary thrust of the workshop, generally because they are single-
issue topics. Most of them are pure security topics and are
concerned with the security perimeter. The last two do not fit into
our classification system at all.
S9. XYZ corporation has two major branches on opposite ends of the
world, and they want to communicate securely over the Internet,
with each branch having IP-level connectivity to the other (not
through application gateways).
S10. I am visiting XYZ corporation, with my laptop. I want to
connect it to their LAN to read my email remotely over the
Internet. Even though I am inside their corporate firewall,
they want to be protect their machines from me.
S11. XYZ corporation is trying to use the Internet to support both
private and public networking. It wants to provide full
connectivity internally between all of its resources, and to
provide public access to certain resources (analogous of
anonymous ftp servers)
S12. The travel industry wants to use Internet to deliver tickets to
customer premises directly in a secure way.
S13. Some hacker is deliberately subverting routing protocols,
including mobile and multicast routing. Design counter
measures.
S14. Part of the Internet is running IPv4 and part is running IPng
(i.e. the Internet is in transition). How can we assure
continued secure operation through such a transition?
S15. A corporation uses ATM to connect a number of its sites. It also
uses Internet. It wants to make use of the ATM as its primary
carrier, but also wants to utilize other networking technologies
as appropriate (e.g., mobile radio). It wants to support all
media (data, voice, video).
Security Considerations
This memo is entirely concerned with security issues.
Authors' Addresses
Bob Braden [Editor]
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (310) 822-1511
EMail: Braden@ISI.EDU
David Clark
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
Phone: 617-253-6003
EMail: ddc@lcs.mit.edu
Steve Crocker
Trusted Information Systems, Inc.
3060 Washington Road (Rte 97)
Glenwood, MD 21738
Phone: (301) 854-6889
EMail: crocker@tis.com
Christian Huitema
INRIA, Sophia-Antipolis
2004 Route des Lucioles
BP 109
F-06561 Valbonne Cedex
France
Phone: +33 93 65 77 15