Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ssh/ssh-minutes-97aug.txt

Text File | 1997-10-10 | 11KB | 210 lines

39th IETF, Munich, August 1997
******

Site Security Handbook (SSH)
=========



Agenda
======

 o status of SSH draft
 o discuss and review comments on USH draft
 o idea of a firewall policy document
 o review schedule and task assignments



Report on Status of SSH Draft
=============================

SSH Document went out for Last Call (expires 22nd August 1997) The editor, Barbara
Fraser has incorporated all comments and corrections, submitted from the list or
through other correspondence, into it. Once the last call expires, the document will
progress to informational RFC.



Discuss and Review Comments on USH Draft
========================================

There was some discussion was about the document structure. Erik came up with the
idea of splitting in two parts. The first part would cover all users, and the second part
would concern only those users who also had administrative control over their
computer. It was decided definitely not to split the document into two documents.

One concern of the group was that to split content into all users and "power" users
might have the result that "power" users wouldn't read the portion for all users. There
was some concensus that a statement upfront could be provided that would guide the
reader.

The group then decided to review the document in two passes. The first pass would be
spent discussing content issues and the second pass would focus on what content should
be moved to the administrative user section.

First Pass
++++++++++

There was discussion concerning using the term administrators when we are really
talking about a special class of users. It was felt that using the term in this context made
it conflict with the usage of the term in the SSH document. Therefore, it was decided
not to use the term "administrator" in this context.

In section 5.2 about Viruses and other Illnesses, it was felt that the last paragraph should
be moved to the beginning of this section to explain the terms for the reader. There was
also a problem with the introduction of Trojan Horses that will be fixed. One subject
that was missing from this section was a discussion about viruses introduced through
email documents and attachments. The editors will add some text on this subject.

Section 5.3 about modems should have a statement added about the "Auto answer
mode". Additionally it might be worthwile to add something about informing the
system administrator whenever a modem is added to a desktop computer.

Section 5.4 is missing content. It covers destruction of information but fails to mention
that unauthorized persons could simply access information or make modifications to
data or systems. The second paragraph starts with something about physical security and
it should be made more clear that we are talking about computers in general which were
left alone by the user. It was also mentioned that simply locking a door can help prevent
unauthorized access to such computers. Given all the discussion, it was felt that the title
of this section should be changed and the editors will try to come up with something
more appropriate, like "Don't leave me..."

Use of encryption by the user was discussed a little bit, and it was clear for the WG, that
it is important to have this topic covered in the document. Some changes were suggested
concerning the corporate user who might have the only knowledge about the encryption
password. It was felt that we should include suggestions about safeguarding encryption
keys to prevent loss of data due to loss of key.

The start of section 5.6 should be changed, since the phrase "third category" is awkward
grammatically. The language is also rough on system administrators and tends to paint
them as the bad guys. This will be changed. Encryption will be presented as just one
additional measure to protect private information. It should also be made clear that
there are different objectives when protecting the files with operating system
mechanisms (access rights) and protecting files' content (encryption). PGP will be used
as an example and we will include comments cautioning users about weak mechanisms.

Section 5.7 will be extended to include warnings to the users about adequately wiping
disk files to prevent the availability of previously deleted data.

Section 5.8 contains a very extreme sentence about never sending sensitive information
by email. But by using strong encryption it might be acceptable. Adding such a remark
would fit with the following paragraph nicely. It was mentioned that The privacy of
email on company computers might be handled very different from country to country
and the statements concerning this subject should be softed a little bit.

There was some duplication noted between the three sections dealing with viruses,
unknown programs and possibilities to execute unknown content. There was
considerable discussion about how to warn users about what they are downloading and
executing. However, it was also felt that we shouldn't get too technical in our discussion
of the issues because we'll lose the reader. For example, a user might not consider a
PostScript file as "code" necessarily. There was discussion how to handle application
modules which are necessary to download in order to be able to obtain the full effect out
of a WWW page or other document. It was also mentioned that a major point we need
to make is that many problems arise by downloading from the net from unknown
sources. There are better chances to get "good" software from a well-known server
affiliated with a product. Or, the local administrator might set up a WWW page with
commonly needed software already collected on a local server. The paragraph about
trojan horses using the name of well-known applications will be moved to the section
about Downloading.

Erik rised the discussion about different mechanisms to protect the download: JAVA
and ACTIVE X. It was decided not to include such details in the document, as the
average user will probably not understand the concepts. Since this subject is very
specific to the Web, any treatment of it will be handled in the WWWW section
anyway. It was decided that we should alert the users about the dangers, but we will not
be able to protect them from using the dangerous and unprotected features. Upcoming
technology might help to solve the problems. It was also mentioned that problems with
downloading are also connected to downloading too much at the same time.

The section about encryption keys (5.11) should go into the relevant section and should
be shortened. Details about key length will not be understood by the user and are not
necessarily important to get the idea right: encryption can be weak and might be weaker
because of export restrictions.

In 7.1 some statements suggesting that users be aware of last log in messages on UNIX
boxes, changes in the user environment, and the addition of new files or directories (and
other specific things) should be included. Examples should be used instead of fuzzy
statements.

Reading the policies of the local site might fit in 7.3 here, especially in case of
incidents. Before informing the whole community (about Good Times for example) the
user should inform the system administrator. This will prevent users from propagating
erroneous information.

Something about how to respond to security alerts should be included, but it will fit
more for the power user section, since most end users will not install software or be
responsible for the status of the software.

Discussion about section 8.1 was that if we get rid of shell accounts and SLIP, it is
really more about services (daemons) and there is no longer any content. Most important
issue to convey is that PPP creates a two-way connection. "How to pick an ISP" is too
limited and there might be other issues which could be handled under a different
heading. We should alert the user that the ISP network should be handled as a public
network. However, it will be very difficult to obtain information concerning the
security mechanisms in use by an ISP. Underlying this is that the user should make sure
that they understand the policies of the ISP and ask questions as needed.

Erik promised to complete a new draft pretty soon (in September). The section about
commandments needs some checks and editing. It should be address every section and
topic covered in the document.

Second Pass
+++++++++++

The second pass was supposed to identify the content to be separated into a section on
administrative users. However, after the discussion, we deferred this discussion until
another draft is available. The thought was that we may not need any separation after
all.



Firewall Policy Document
========================

A presentation was given on a possible firewalls framework document. Firewall
policies are very difficult and desperately needed. Often the firewall is the only security
mechanism between the local network and the public network. There are some typical
questions which can be addressed to help the administrator. Guidelines - not necessarily
all answers - for these questions are needed. There was some discussion as to whether
such a document belonged in this working group. Since it would be an extension of the
material in the SSH document, the thought was that if it was to be, it did belong in the
working group. It was also suggested that we might incorporate the material into the
firewalls section of the SSH document. But, since this would cause a new Last Call and
delay the release of the SSH document, this suggestion was rejected.

Discussion centered around the scope of the guidelines given. To be able to ask the right
questions would be the main benefit for the administrators. In comparision to existing
books the benefits would be that it is free and it would give the people a document that
had established quality (because it had gone through the IETF process) and could be used
as a starting point for further reading.

After hearing a presentation on the proposed content outline, it was decided that a first
draft would be constructed to be submitted to the list by the next IETF meeting. The
group will review the content and decide at that time how it wants to proceed.

Marc Blanchet will carry on as editor of the firewalls document but we won't
associated the ssh working group name yet.



Update Schedule and Task Assignments
====================================

22. August 1997:
   End of last call for SSH document
30. September 1997:
   New draft of USH document
31. October 1997:
   First draft of Firewall document
13. December 1997:
   Last input to USH document during December IETF
31. December 1997:
   Last ID version and submit to IESG as informational RFC

One slot (two hours) will be requested for the next IETF in December.



Current Maintainer:DFN-CERT / [e-mail]