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.