CURRENT MEETING REPORT

Reported by Barbara Fraser, Phil Nesser, and Gary Malkin

Minutes of the Security Site Handbook Working Group

The SSG Working Group met twice during this IETF. The first session focused on the latest draft of the Site Security Handbook (for System Administrators). The second session began work in earnest on the Site Security Handbook for Users.

SESSION ONE

1. Solicit notetaker

Phil Nesser volunteers again--what a great guy!

2. Review and assign missing pieces

We want to put to bed the entire first document with two more passes: one for content, and one for grammar. Missing pieces and those who volunteered are as follows:

• 4.1.2 Kerberos: Phil Nesser volunteered since the original personhasn't submitted any information.
  
• 4.6 Audits - Gary Malkin will take a crack at it. This section should look at it from system administration view. Need to point out two concepts:
  • What information to log
  • How to log it

Someone asked for a list of tools for this section. It was pointed out that there is an appendix. We decide not to pursue it other than what we have now.

• 6.0 Compliance Management

What is this section? No one really remembers. Is this about a site self policing its own policies? Barbara Fraser volunteered to add bullet to Chapter 6 list on checking for compliance to policies and procedures. Frank Byrum brought up independent auditing of policies. Make sure the above points out that someone else should do the auditing. He will send some text to Barbara Fraser for Chapter 6.

• Bibliography and References Section

Frank Byrum (byrum@infi.net) will do the bibliography and reference section. It was suggested that he talk to Steve Bellovin since he has a lot of online references and citations. Gary Malkin will do the index. Barbara asked for help on how to do TOC's in nroff. Gary Malkin will send her info.

3. Review of current document and text.

• Chapter 1
  • Introduction: Changed audience introduction and take out the word "system". Added section 1.5 per comments from last review. Risk analysis sections have been taken from RFC 1244 with minor mods.
  • 1.4 Related work-There was discussion as to whether we should mention the users guide that this working group is also developing? Joyce said no. We can say that the the SSH Working Group has a work item to produce a users guide.
  • 1.6.1 BYF has put place holders in the document for references and will coordinate with Frank Byrum.

• Chapter 2
  • 2.1.2 AUP section was added. Second paragraph is new.
  • 2.1.3 Added text based on Dallas meeting. Added paragraph about dissemination of information.
    

There was discussion as to whether we want to provide guidance on setting up multiple privileged accounts as opposed to sharing a single privileged account, mentioning the corresponding additional need to monitor the multiple accounts. It was decided that this should be covered in section 4. It was realized we don't have an accountability section, David Holmes (delphys@bunyip.com) volunteered to write one.

• Chapter 3
  • 3.2.3 Moved all previous text from 3.1.2.X here. It's much better.

• Chapter 4

Title was changed to "Security Services & Procedure". After significant discussion, we decided to remove the appendix on cryptography. We have sections on various security services and Russ Mundy will review the text and add pointers to references where needed. That brought up the question of whether we should add pointers to other Security WG's? Russ Mundy will add paragraph to 3.2.3.1 about Secure DNS. We discussed what to do about client side information. Erik Huizer suggested a BCP earlier, and this might be a place for the client side. We agreed to add a section to the Introduction pointing out the tremendous amount of work going on in the IETF. How about section

• 4.1 BYF will do it.
• 4.1 Authentication-Approved.
• 4.2 Confidentiality

Approved

• 4.3 Integrity

Add sentence about digital signatures? The group had not strong feelings about the inclusion of text regarding digital signatures.

• 4.4 Authorization.

Paragraph 3 is dead wrong. Gary will rewrite it.

• 4.5 Access
• 4.5.4.2 parenthetical comments change this to (see section 4.1.4)

Remove last paragraph? Just change this to say "If possible," before second sentence. Delete parenthetical comment about caller id.

• 4.6 Auditing

Gary will work on it.

• 4.7 Securing backups

Gary has some comments about off site storage. He will send them to BYF. Should we say anything about privacy of the indexes of the data. Normal policy about your system should be appied to backup material. Russ Mundy will provide text to BYF.

• Chapter 5

Barbara will fix line cut off that Gary points out. She'll also check out formatting throughout the document.

• Chapter 6

We agreed that we need dedicated Reviewers for each chapter. The following people have volunteered, we'll have to solicit others from the list:

• Chapter 1
• Chapter 2
• Chapter 3 Lorna Leong (lorna@singnet.com.sg)
• Chapter 4 Russ Mundy ()
• Chapter 5 Frank Byrum
• Chapter 6
  

We should do an official last call. This draft will be submitted after this IETF as -02. We then need an -03 before the final one -04 by June 1. Content needs to be in by 4/15, so -03 will be published by 5/1. Then -04 will be out by 6/1 and go into last call for Montreal.

Erik Huizer suggested that after we get this documents out, we write a short (2-4 pages) BCP with non-controversial issues with pointers back to the SSH.

SESSION TWO

The target audience is the END USER.

This session discussed general structure and content for the User Handbook document. It was suggested that we could have a list of things to do, say 10 or 20 points? Probably things should be divided into topics, like "AUTHENTICATION" but these would have to be palatable to users. The topic "AUTHENTICATION" is probably too technical for many users. Further, explanations of terms could be provided in a cross index, or appendix.

Another person suggested doing it all in Q&A style. He received the rebuttal that this is pretty hard to use as a reference.

Still another person suggested the document be a GUIDE not a reference or a list of points-to-bear-in-mind.

It was pointed out that the reader should not have to read a lot, yet we don't want one-liners, either. There was agreement that around 3 lines per item would be good. So, 1 line of topic, followed by 2-3 sentences of clarification appeared to be the presentation style of choice.

The overall topic for the document is to convey to the user that they have a responsibility in making their site secure. It was further added that it is most important for readers of the doc to learn how to do that.

How does a user follow a policy? Someone said this question is kind of like netiquette. Your responsibilities, both general and specific, need to be understood to be able to follow your site's security policy. It was noted that there is a big range - between a corporate site with a lot of rules and someone at home, (using www, etc.).

It was noted that in any case, even with ISPs with no security policy, there is a notion of appropriate use. For example, one should be careful of using applications from off the net. It can destroy one's own data or that of the ISPs, or be a nuisance, etc.

Motivational words up front are imperative: URGENCY and IMPORTANCE need to be conveyed. The policy should be crystal clear, if the user is hazy, she should speak to the sys admin.

It was noted that the user security handbook may well be tailored by sites for their own context.

Gary Malkin volunteered to be the document editor.

We will try to use humorous or chilling examples throughout. Barbara will solicit stories on various lists. There is an example of some sort in rfc 1135?

Next, we launched into a bunch of brainstorming:

• PASSWORDS: One should never divulge them, even to the administrator. Administrators should not reset passwords for users. Cover your own butt by not allowing others to do wrong using access you shouldn't have provided. choose a good password. Don't leave it laying around.
• SCAMS or SOCIAL ENGINEERING: It is important not to be browbeaten or duped into breaking the policy. We later dubbed this "PARANOID IS GOOD" The anecdote of Adam Michnik yelling at people and pretending to be their boss to get them to give access illustrates this.
• POLICIES ARE THERE FOR A REASON: was another topic thrown up as a potential.
• SECURITY PROCEDURES: Destroy sensitive information and encrypt files and backups.
• ONE TIME PASSWORDS, etc.: Users should realize there are sniffers, etc. so they should be aware of the utility of better authentication and encouraged to use it if possible and even advocate its adoption within their organization.
• HOME ALONE: what to do as an independent user without policies. Leaving PPP up exposes your machine. If the modem can answer the phone and the machine is configured to respond, you could be attacked thinking that your machine is not connected.
• WHAT IS DISCONNECTED? The anecdote of a user who thought turning off the monitor protected the machine was told by BF. Note that logging out is important but sometimes not enough.
• BEWARE OF DAEMONS was suggested to inform people of the risk of running servers.
• Other sections described were: THE WIRES HAVE EARS and BACK DOOR
  

It is ok if there is redundency.

We will find info for terms in the user glossary.

We worked the password example for some time. Gary also led us in a discussion of the table of contents, which he will submit to the list.

C. Dates

SSH dates will be very soon for -02.

• new content 4/15
• new draft 5/1
• review intensely
• final draft 6/1
• last call for informational rfc
  

USH dates will be: get writing to GM by 5/20 GM to submit draft by 6/7 to have it by the next ietf.