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 >
Encoding:
Text File  |  1997-05-29  |  7.9 KB  |  166 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3. 38th IETF, Memphis, Tenn. - April 1997
  4. **************************************
  5.  
  6. Site Security Handbook (SSH)
  7. ============================
  8.  
  9. Prepared by Matthias Koerber and Klaus-Peter Kossakowski 
  10.  
  11. The SSH working group met once during the Memphis IETF. 
  12.  
  13. Agenda
  14. ++++++
  15.  
  16.  o Brief review of new SSH draft 
  17.  o Review of USH draft 
  18.  o Update schedule 
  19.  
  20.  
  21.  
  22. Brief Review of the new SSH draft
  23. +++++++++++++++++++++++++++++++++
  24.  
  25. The  SSH  document is  basically  finished.  One outstanding  issue  was
  26. whether to include the annotated  bibliography with the draft. The group
  27. voted  to separate  the  annotated bibliography,  confirming an  earlier
  28. decision  made  last summer.  We  will  still include  the  alphabetical
  29. reference section.  To help  the individuals responsible  for completing
  30. the annotation, group members were encouraged to send short descriptions
  31. of documents to the list.
  32.  
  33. Contributing  authors need  to  send information  to Barbara  concerning
  34. their current organization and their email address.
  35.  
  36. No content changes will be made  before submitting the draft towards the
  37. standard process.  Barbara will take  care about editing  and correcting
  38. typos, etc. Additionally she requested help to populate the recent draft
  39. with actual references, volunteers should contact Barbara directly.
  40.  
  41.  
  42.  
  43. Review of USH draft
  44. +++++++++++++++++++
  45.  
  46. The rest  of the meeting was  spent reviewing the current  User Security
  47. Handbook.  It was  felt that  the  introduction needed  to describe  the
  48. different kinds of users: those that  own and maintain their system, and
  49. those that  use office  systems (and  don't have  administrative control
  50. over them). It is important the the  reader be able to read the document
  51. and know  exactly what his  responsibilities are. For example,  we don't
  52. want a user to think he should reinstall  a system if he is a user of an
  53. office system where other personnel  have the responsibility to maintain
  54. the system.
  55.  
  56. A section by section review proceeded with Gary Malkin recording all the
  57. recommended changes.In  section 1, the following  issues were discussed:
  58. Anecdotes will be kept, but without  discussion about the meaning of the
  59. story. It  was felt that  anecdotes in  general would make  the document
  60. more readable  and enjoyable. Right now  there is only one  and while we
  61. want  to have  one for  each section,  we won't  hold up  publishing the
  62. document for them.
  63.  
  64. There  is  some  redundancy  which  must  be  removed  from  section  1.
  65. The  language  of  the  abstract  sets a  harder  tone  related  to  the
  66. responsibility of the user than originally intended.
  67.  
  68. Section 2 does  not contain much content yet. There  was some discussion
  69. about  including  a  checklist  containing  the  content  of  the  other
  70. sections. In previous discussion it was already decided to not put it at
  71. the end. Creating the checklist was still  an issue and work on this was
  72. deleyed until later.
  73.  
  74. The title of section 3 really needs a subtitle to explain "READ ME". The
  75. story of 3.2 is really good, but it should be used as an introduction to
  76. the whole section. (Similar, anecdotes should be used as motivation into
  77. the sections, so on level 3 and not on sublevel 3.1, 3.2, etc.)
  78.  
  79. Discussion in section  4 was devoted to Trojan horses  which might trick
  80. the user to  give their passwords away  in 4.1. Although this  is an old
  81. trick,  the group  felt it  would be  beneficial to  keep the  paragraph
  82. but  elaborate  more  on  the  "realizing  wrong/strange  behavior"  and
  83. "informing the administrator". Re-usable passwords by themselves are not
  84. acceptable, with the exception of logging on from the console. Therefore
  85. it is not just a problem of public networks.
  86.  
  87. The discussion about  viruses in 4.2 is missing more  proactive steps to
  88. avoid viruses  in the first  place. There was also  extensive discussion
  89. about whether we should recommend  that users discovering a virus should
  90. warn other  people about it. The  concern was whether the  user would be
  91. knowledgeable enough to distinguish between a real virus and a hoax, and
  92. we  didn't  want to  recommend  something  that  would result  in  users
  93. propagating hoaxes.  A good starting point  is to encourage the  user to
  94. inform  the direct  sender,  and  work with  him  first  to address  the
  95. problem. To avoid  hoaxes, the end user should not  report to the "whole
  96. world",  but  to a  technically  knowledgeable  personwho can  find  out
  97. determine whether or  not the virus is real. More  information about the
  98. different kinds of viruses (and related programs, but not Trojan horses)
  99. should be included, as well as suggesting  that the user keep up to date
  100. with what can damage information, programs and systems.
  101.  
  102. Modems in 4.3 must be addressed from a more overall point of view, as it
  103. is  now very  technical. The  overall perspective  should be  concerning
  104. permission to  connect anything  to a computer,  with modems  as popular
  105. example. Together  with 4.4  about terminals, discussion  about multiple
  106. passwords came up.
  107.  
  108. Related to  encryption it was felt,  that users should be  encouraged to
  109. use such programs and  not be scared. But it is difficult  to get an out
  110. of the box solutions. We will also include guidance about how encryption
  111. is useful for  other things beside communication.  For example, specific
  112. files can be protected from browsing by others (such as when giving kids
  113. and their friends access to a computer while keeping the tax declaration
  114. on  the same  computer encrypted  and  making sure  that backups  exist,
  115. if  the files  are  deleted).  Each user  should  be  encouraged to  use
  116. the  strongest mechanism  available and  understand, that  the available
  117. mechanisms can contain some severe limitations.
  118.  
  119. Section 4.9 and  4.10 should be switched, as they  relate to each other,
  120. but the  content of 4.9 is  really more specific than  4.10. Beside some
  121. typographical errors, nothing else was discussed.
  122.  
  123. We discussed  the issues  related to remote  sites and  connectivity and
  124. management  issues.  These are  discussed  elsewhere  so 4.12  might  be
  125. redundant.
  126.  
  127. Section 5 is about social engineering  and is really good, but it should
  128. be compressed  a little bit.  An editing pass  will help here.  The last
  129. paragraph  should be  removed,  as  it relates  to  policies, which  are
  130. covered elsewhwere.
  131.  
  132. Section 6  covers much of the  content already addressed in  4. One idea
  133. was to replace 4.12 by it.
  134.  
  135. Section 7 must state clearly  that there are differences between someone
  136. just  using  a system  and  someone  who  is  also responsible  for  the
  137. administration of  the system. There  was some confusion about  the last
  138. sentences of 7.2, which needs clarification.
  139.  
  140. In  section 8  for daemons  examples must  be provided  to make  readers
  141. understand what it is all about. Even  if the user will get a dynamic IP
  142. address, users  will turn on  services anyway, so  it is not  limited to
  143. fixed IP  addresses, which are  usually used for providing  services. It
  144. might be the case, that this  topic really belongs in section 4. Another
  145. topic  is the  preconfiguration of  systems, as  the user  will have  to
  146. search for the right  way to disable it. So it  is important to realize,
  147. what services are running before connecting to a network.
  148.  
  149.  
  150.  
  151. Update schedule
  152. +++++++++++++++
  153.  
  154. The final SSH draft will be out by  May 15. This will go to the list and
  155. to the internet-draft  editor. Two weeks later it will  go to last call.
  156. There  may be  timing problems  related to  cross-references in  the two
  157. documents. Because of  the process it might be tricky,  and Barbara will
  158. work with  Joyce to  handle this  issue. The USH  will be  referenced as
  159. "work in progress".
  160.  
  161. We plan a new draft of the USH  at least every 6 weeks. Gary will submit
  162. the current draft to Internet Drafts immediately after this IETF meeting
  163. with the next version due around the  end of May. A third version should
  164. be submitted before the next IETF in August.
  165.  
  166.