spwg minutes

[Richard Pethia <[e-mail]>]

Security Policy Working Group

Chairperson: Richard Pethia, [e-mail]

MINUTES FOR August 1 Meeting at UBC IETF
----------------------------------------

Minutes submitted by Paul Holbrook.

Richard Pethia was not able to attend this meeting, so the meeting was
co-chaired by Steve Crocker and Paul Holbrook.

The initial part of the meeting focused on history of the group and
the efforts thus far.  We noted that the group had not made the
progress it had hoped for; at the previous meeting in Pittsburgh,
seven people had agreed to produce position statements on various
issues, but only three of those statements had shown up.  (Two of the
statements are included in these minutes; the other one from James Van
Bokkelen has been released as RFC 1173.)

After a general discussion of the scope of the group and it's
relationship to the work of the Site Security Policy Handbook WG
(SSPHWG), Steve Crocker came up with some 'strawman' statements that
might be in an Internet security policy.

Steve stressed that these were statements that he didn't necessarily
agree with, but were intended to be worded 'strongly' to provoke
discussion.  The group agreed the Steve had certainly provoked them.

After a discussion of these statements (which we could not retrieve
for these minutes), Steve proposed that everyone spend a few minutes
writing up their own statements that they would include in an Internet
security policy.  This exercise worked very well, and the responses
from the group showed a surprising amount of agreement.  Joel Jacobs
from Mitre took the task of trying to synthesize the writings of the
group into a single strawman security policy.  A summary (and
interpretation) of some of the thoughts of the group is included at
the end of these minutes.



The goal of the group is to have some solid draft of an Internet
security policy by the December IETF at the University of Colorado.
To that end, a small group of people may gather in September to hammer
out a solid draft of the security policy for other to critique.

- -------------------------
J. Paul Holbrook
Computer Emergency Response Team, SEI/CMU
August 22, 1990

Security Policy Themes from the UBC Security Policy WG Meeting


What follows are some of the themes the group seems to agree upon
coupled with explanatory paragraphs in which I try to interpret the
thinking of the group.

A caveat: the information in this document has been filtered several
times.  Steve Crocker provided the original bullets, and thus provided
his own view of what the group said.  The paragraph after each bullet
is my interpretation of what the group was thinking about.  In
particular, where the explanation says people 'should' do something,
that does not mean that everyone agreed to propose this, just that
this is one interpretation of where the group was going.  The result is
that the people who were at the meeting may not agree with what
follows.


 * Internet, regionals/backbones, sites, hosts -- all should have
   security policies.

   Security policies and procedures are needed at all levels of the
Internet.  The policies will be different for different groups, and
the general level of security expected may be different.  For example,
the policy may encourage regional networks to protect the network
infrastructure such as the routers and other network equipment, but
may put the burden of privacy on hosts.  Thus, a regional would make
it's best effort to protect the network, but would not provide a
guarantee of privacy for the hosts that use it.  


 * Emphasis on user responsibility, identification, and
   accountability.

   The policy should state clearly that users are responsible for
their own actions regardless of the level of security a site
maintains.  By analogy, even if you leave your front door unlocked,
that doesn't give someone else permission to enter your house.

   Sites should also have policies that support identifying and (if
necessary) accounting for individual users.  If your site is used to
break into another site, that other site may ask for your help in
tracking down the problem.  It should be possible for you to figure
out what user's account at your site was used.  This requires that all
users be individually identified, and that enough accounting records
be kept to identify when users were on systems.  (On Unix systems, the
normal login accounting may well be sufficient for what we're after
here.)

   This last requirement is likely to be controversial.  There are
sites that keep guest or group accounts for their own convenience,
terminal servers that allow access out to the Internet without logging
into a local system, and so forth.  There was some irony in this
proposal, since we all enjoyed this kind of open access out to the
Internet at UBC, yet this was the very kind of access we were
proposing limiting.
   
   
 * Emphasis on mutual assistance
   - Preference for investigation
     - Concern for privacy

   Where possible, sites should assist each other in investigating
security incidents.  Sites should provide contact points to help
facilitate communication about security problems.

   When a security incident occurs, a site has two main choices:

      a) try to watch or trace the intruder(s) in an effort to see how
widespread the problem is and hopefully identify who is responsible;

      b) identify the vulnerabilities or lapses that led to the
incident, clean up the systems and lock the intruder(s)

   Some people leaned towards encouraging sites to investigate
problems.  In many cases, locking an intruder out will force them to
find another site to use, but will not stop them from breaking into
systems.  The decision about what to do about an intrusion will always
be up to the site, but the community standard should be to try to
solve the problem.  This does not necessarily advocate prosecution or
law enforcement involvement.  Once an intruder is identified, there are
many possible courses of action.  


 * Encouragement to use good security controls

   Policies and procedures are not a substitute for putting good
security controls in place and making sure systems are securely
configured.  The policy should encourage sites to put useful security
controls in place.

- ------------------------

Vint Cerf
CNRI
July 31, 1990 

The Need for Unforgeable User Identification

FIRST DRAFT

  Summary
  -------

This brief memorandum motivates the need for Internet mechanisms and
facilities for authenticating user identification and for assuring that
such identification cannot be forged.


  Introduction
  ------------

The Internet has reached a point in its evolution where some of the
services accessible require compensation from the using parties (or an
entity which accepts responsibility for paying for services rendered).

At the application level, such compensation is required for use of
information services such as bibliographic databases (National Library
of Medicine MEDLARS; Research Libraries Information Network, etc.)

Commercial electronic messaging providers (e.g. MCI Mail, Compuserve,

ATT Mail, Sprint Mail, BT Dialcom, QUIK-COMM, etc.) normally charge
for their services.  Some, such as Compuserve and MCI Mail provide
access to commercial information services (e.g. Dow Jones News &
Retrieval).  Under the present terms and conditions, commercial email
services do not charge Internet users for delivering email sent from
Internet sites to commercial email boxes.  Even if this provision
remains in place, there are other services such as fax and hardcopy
delivery, bulletin boards and information services which, at present,
are not accessible to Internet users because there is no secure way to
identify a billable account to which to charge these special services.

Passwords carried in plaintext form across the Internet, whether in a
Telnet session or via email, are not sufficiently protected to make
the risk of compromise acceptable.  Moreover, there is no currently
standardized means of authenticating whether the use of a particular
billable account is legitimate (once a password is compromised, it can
be used at will, for simple, password-based account identification
methods.)


  Example Requirements
 ---------------------

At least two applications need reliable, secure account authentication
capability:

	(1) remote login
	(2) email store and forward services

In the first instance, it is required that the user/account
identification provided to the server be protected from capture and
re-use by hostile third parties and that the serving site can verify
that the identification has not been forged.

In the second case, it is required that at an email relay, an arriving
message to be passed into the next email system can be reliably and
authentically associated with an account in the next email system, if
necessary, for purposes of accounting and validation that the message
originator is authorized to use the services requested.

For example, it should be possible for an Internet user to send email
to fax recipients by way of ATT Mail and for ATT Mail to correctly
account and bill for this usage.  This means that the originator must
supply information associated with a message which identifies
                   ----------
account information needed to complete processing of the message at
the Internet/commercial email interface.  The provision of this
account identifying information needs protection from compromise and
validation that its use is legitimate.

  Questions
  ---------

1. Can the same techniques work for remote login and store-and-forward
services?

2. Even if a "password" can be encrypted for confidentiality and
signed for authenticity, how can the recipient be sure that the
encrypted and signed object has not been hijacked by an abusing third
party?  (i.e. "stealing and reuse")

3. Given that there must be some kind of authenticated exchange
between user and server just to set up an account, can we take
advantage of this to carry out any additional exchanges needed to
support the confidentiality and authenticity required for these
account validation applications?


---------------------------------------

J. Paul Holbrook
Computer Emergency Response Team, SEI/CMU
June 1, 1990

Scope of the Internet Security Policy



This proposal deals with two areas that the Internet Security Policy
is concerned with: the scope of the Internet Policy, and lines of
authority or responsibility at a site.  These are separate issues, so
I'll treat them that way.


SCOPE OF THE POLICY

The Internet Security Policy should not mandate security policies for
sites beyond what is necessary for maintaining the security of the
Internet.  The policy should not mandate the form of a site's internal
response to security problems.  However, it should require that a site
have policies in place which meet a minimum set of requirements to
allow effective prevention of and response to Internet security
problems.  Helping a site develop a more complete set of security
policies and procedures is the goal of the the Site Security Policy
Handbook.

The goal of the policy is to ensure that each site responsibly
protects and audits access to the Internet, and maintains a point of
contact so that each site can get information about security problems
and also assist others in dealing with security problems that involve
their site.

The policy covers all "network-capable" devices that may affect the
Internet.  Thus, in addition to hosts, terminal servers, routers,
and other network management devices are covered.  Other machines that
may indirectly allow unaudited access to the Internet are also
covered.  For example, if a host that has access to the Internet also
trusts other hosts on a site's local network, the policy covers those
other machines as well.  As an example, if an Internet host trusts a
local PC via some mechanism such as rlogin or special trusted
accounts, a user might be able to use the PC to gain access to the
Internet without proper auditing.  In this case, the PC is covered
under the policy.  (If the Internet host does not trust the PC, the PC
does not come under the policy.)



SITE AUTHORITY

In this proposal, I use the term `site' to mean every resource-owning
organization, including regional networks and other entities.  I've
used the terms 'MUST' and 'SHOULD' in capitals to help point out
suggested policy directions.

    [Comments in brackets are notes to help explain the reasoning
     behind some of the statements.  These comments would not appear
     as part of a policy, though they might appear as a commentary
     that goes along with the policy.]


Site Security Contact

Every site MUST have a site security contact.  This may or may not be
the same as the normal site contact or network manager.  A site
security contact can be an individual or an organization.  The site
security contact SHOULD be familiar with the technology and security
of all systems at that site.  If that is not possible, the security
contact MUST be able to get in touch with the people that have this
knowledge 24 hours a day.

    [At the CERT we've got in touch with sites only to find out
     that they have no idea who is responsible for security or how to
     get in touch with them.]

    [A point of terminology: in his `responsibility' writeup, James
     VanBokkelen refers to `network managers' and `host managers'.
     The site security contact is a peer to the network manager; it
     might even be the same person.  Others in the Internet community
     have used the term `site contact', which I've used because it
     helps to emphasize that a site security contact may have to deal
     with both network and host issues.  Certainly a regional network
     or other network provider can (and should) have a `site security
     contact.'  However, the terminology is certainly open to change.]


Security Contact Availability

The site security contact MUST provide other designated organizations
in the Internet with a 24 hour point of contact.  At a minimum, this
should be a phone number which is answered during `business hours' 5
days a week, and equipped with an answering machine that is checked at
least once every day (including weekends) to cover off hours.  Sites
SHOULD consider providing `real time' response: e.g., home phone
numbers, pager numbers, or other means of contacting people.  However,
being able to get directly in touch with the security contact at any
time is not required.

     [This is a compromise statement; it's hard to require a site to
     provide around-the-clock response without proof that it would be
     worth the cost.  At the CERT we've found almost all problems can
     be dealt with by having a contact who is available during
     business hours.  However, large sites or sites that care about
     the availability and security of their systems will probably want
     to provide 24 hour access to their security contact.]

Sites MUST ensure that some backup security contact can be reached if
the primary security contact is unavailable.  This can take the form
of a secondary contact person or organization.  If outside
organizations must use some different procedure to get to the backup
security contact, sites MUST ensure that these procedures are
communicated to the outside organizations.

The `designated' or `outside' organizations have this contact information
might be a local Network Control Center or Network Information Center,
or might be security response centers such as CERT.  Since
security organizations might need access to this information anytime,
organizations that keep this information MUST make it available 24
hours a day.

    [ The User Connectivity Problem (UCP) working group is working on
    the problem of how to get site contact information propagated
    around so that network problems can be dealt with.  We should
    consider using whatever means they come up with for distributing
    this kind of information.  In any case, the specifics of how this
    works are an operational matter that doesn't belong in a policy. ]


Security Policy Issues

Although the initial response to a security incident is often a
technical one, policy issues also need to be dealt with.  Should an
intruder be shut out or watched?  Should law enforcement be involved?
Should a site disconnect itself from the network to avoid a worm or
intruders?  These decisions are not strictly technical; they may
affect many people.  Sites MUST ensure that people with the authority
to decide these kinds of issues are available in the event of a
serious security problem.

If the site security contact does not have the authority to make these
kinds of decisions, sites are encouraged to have a 24 hour
administrative contact.  (This administrative contact does not need to
be visible to people outside the site.)  Sites SHOULD also have
policies that state who has the authority to make decisions and take
actions in response to security problems, and under what circumstances
administrators or decision makers should be brought in on an active
security incident.  The goal should be that a site security contact
can quickly (i.e., in a few hours) take action to deal with a security
problem, if necessary getting in touch with someone who can authorize
their actions.

At some sites, policy makers could give advance authorization to the
site security contact and other system managers.  For example, the site may
give their technical people the authority and license to make their
best efforts to deal with security problems.  In this case, the policy
also protects the technical people from `retribution' from policy
makers after the fact.


     [The motivation here is that policy makers should be involved
     early on if a serious security incident is underway.  Policy
     makers may have little to do with the day-to-day operation of
     systems, but they will be concerned if a serious security
     incident has serious impact on a site and it's operation.  Among
     other things, if decision makers are not involved and understand
     the nature of security problems, they might impose policies after
     the fact to `deal with the security problem.'  For example, the
     CERT has heard of sites where the local policy maker's response
     to a security incident was to advocate permanently disconnecting
     from the Internet.

     However, since this issue is mostly a matter of site internal
     policies, the Internet Security Policy should not mandate an
     administrative contact.  The Site Security Policy Handbook will
     help flesh out this area by going into detail about how site
     policy makers should be involved in setting security policy and
     procedures.]