home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
ssh
/
ssh-minutes-97apr.txt
< prev
next >
Wrap
Text File
|
1997-05-29
|
8KB
|
166 lines
Editor's Note: These minutes have not been edited.
38th IETF, Memphis, Tenn. - April 1997
**************************************
Site Security Handbook (SSH)
============================
Prepared by Matthias Koerber and Klaus-Peter Kossakowski
The SSH working group met once during the Memphis IETF.
Agenda
++++++
o Brief review of new SSH draft
o Review of USH draft
o Update schedule
Brief Review of the new SSH draft
+++++++++++++++++++++++++++++++++
The SSH document is basically finished. One outstanding issue was
whether to include the annotated bibliography with the draft. The group
voted to separate the annotated bibliography, confirming an earlier
decision made last summer. We will still include the alphabetical
reference section. To help the individuals responsible for completing
the annotation, group members were encouraged to send short descriptions
of documents to the list.
Contributing authors need to send information to Barbara concerning
their current organization and their email address.
No content changes will be made before submitting the draft towards the
standard process. Barbara will take care about editing and correcting
typos, etc. Additionally she requested help to populate the recent draft
with actual references, volunteers should contact Barbara directly.
Review of USH draft
+++++++++++++++++++
The rest of the meeting was spent reviewing the current User Security
Handbook. It was felt that the introduction needed to describe the
different kinds of users: those that own and maintain their system, and
those that use office systems (and don't have administrative control
over them). It is important the the reader be able to read the document
and know exactly what his responsibilities are. For example, we don't
want a user to think he should reinstall a system if he is a user of an
office system where other personnel have the responsibility to maintain
the system.
A section by section review proceeded with Gary Malkin recording all the
recommended changes.In section 1, the following issues were discussed:
Anecdotes will be kept, but without discussion about the meaning of the
story. It was felt that anecdotes in general would make the document
more readable and enjoyable. Right now there is only one and while we
want to have one for each section, we won't hold up publishing the
document for them.
There is some redundancy which must be removed from section 1.
The language of the abstract sets a harder tone related to the
responsibility of the user than originally intended.
Section 2 does not contain much content yet. There was some discussion
about including a checklist containing the content of the other
sections. In previous discussion it was already decided to not put it at
the end. Creating the checklist was still an issue and work on this was
deleyed until later.
The title of section 3 really needs a subtitle to explain "READ ME". The
story of 3.2 is really good, but it should be used as an introduction to
the whole section. (Similar, anecdotes should be used as motivation into
the sections, so on level 3 and not on sublevel 3.1, 3.2, etc.)
Discussion in section 4 was devoted to Trojan horses which might trick
the user to give their passwords away in 4.1. Although this is an old
trick, the group felt it would be beneficial to keep the paragraph
but elaborate more on the "realizing wrong/strange behavior" and
"informing the administrator". Re-usable passwords by themselves are not
acceptable, with the exception of logging on from the console. Therefore
it is not just a problem of public networks.
The discussion about viruses in 4.2 is missing more proactive steps to
avoid viruses in the first place. There was also extensive discussion
about whether we should recommend that users discovering a virus should
warn other people about it. The concern was whether the user would be
knowledgeable enough to distinguish between a real virus and a hoax, and
we didn't want to recommend something that would result in users
propagating hoaxes. A good starting point is to encourage the user to
inform the direct sender, and work with him first to address the
problem. To avoid hoaxes, the end user should not report to the "whole
world", but to a technically knowledgeable personwho can find out
determine whether or not the virus is real. More information about the
different kinds of viruses (and related programs, but not Trojan horses)
should be included, as well as suggesting that the user keep up to date
with what can damage information, programs and systems.
Modems in 4.3 must be addressed from a more overall point of view, as it
is now very technical. The overall perspective should be concerning
permission to connect anything to a computer, with modems as popular
example. Together with 4.4 about terminals, discussion about multiple
passwords came up.
Related to encryption it was felt, that users should be encouraged to
use such programs and not be scared. But it is difficult to get an out
of the box solutions. We will also include guidance about how encryption
is useful for other things beside communication. For example, specific
files can be protected from browsing by others (such as when giving kids
and their friends access to a computer while keeping the tax declaration
on the same computer encrypted and making sure that backups exist,
if the files are deleted). Each user should be encouraged to use
the strongest mechanism available and understand, that the available
mechanisms can contain some severe limitations.
Section 4.9 and 4.10 should be switched, as they relate to each other,
but the content of 4.9 is really more specific than 4.10. Beside some
typographical errors, nothing else was discussed.
We discussed the issues related to remote sites and connectivity and
management issues. These are discussed elsewhere so 4.12 might be
redundant.
Section 5 is about social engineering and is really good, but it should
be compressed a little bit. An editing pass will help here. The last
paragraph should be removed, as it relates to policies, which are
covered elsewhwere.
Section 6 covers much of the content already addressed in 4. One idea
was to replace 4.12 by it.
Section 7 must state clearly that there are differences between someone
just using a system and someone who is also responsible for the
administration of the system. There was some confusion about the last
sentences of 7.2, which needs clarification.
In section 8 for daemons examples must be provided to make readers
understand what it is all about. Even if the user will get a dynamic IP
address, users will turn on services anyway, so it is not limited to
fixed IP addresses, which are usually used for providing services. It
might be the case, that this topic really belongs in section 4. Another
topic is the preconfiguration of systems, as the user will have to
search for the right way to disable it. So it is important to realize,
what services are running before connecting to a network.
Update schedule
+++++++++++++++
The final SSH draft will be out by May 15. This will go to the list and
to the internet-draft editor. Two weeks later it will go to last call.
There may be timing problems related to cross-references in the two
documents. Because of the process it might be tricky, and Barbara will
work with Joyce to handle this issue. The USH will be referenced as
"work in progress".
We plan a new draft of the USH at least every 6 weeks. Gary will submit
the current draft to Internet Drafts immediately after this IETF meeting
with the next version due around the end of May. A third version should
be submitted before the next IETF in August.