NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Barbara Fraser <byf@cert.org>
User Services Area Director(s):
Joyce Reynolds <jkrey@isi.edu>
General Discussion:ssh@cert.org
To Subscribe: ssh-request@cert.org
Archive: ftp://info.cert.org/pub/ietf/ssh
The Site Security Handbook Working Group is chartered to create two documents: (1) a revised handbook that will help system and network administrators develop their own site-specific policies and procedures to deal with computer security problems and their prevention and (2) a new handbook for users. The text of these documents will be developed from the existing RFC 1244, plus needed revisions and additions.
Goals and Milestones:
· Overview of the Site Security Handbook Working Group
Minutes of the Site Security Handbook (SSH) Working Group
Reported by: Matthias Koerber and Klaus-Peter Kossakowski
The SSH working group met once during the Memphis IETF.
I. Brief Review of New SSH Draft
III. Update schedule
I. 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.
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 that 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 that 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 is still an issue and work on this was delayed 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 that 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 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 person who can 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 a 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 solution. 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. Besides 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 elsewhere.
Section 6 covers much of the content already addressed in Section 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 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.
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 six 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.