Security Area Director: o Jeff Schiller: jis@mit.edu Area Summary reported by Jeff Schiller/MIT and Jim Galvin/TIS The Security Area within the IETF is responsible for development of security-oriented protocols, security review of RFCs, development of candidate policies, and review of operational security on the Internet. The Area Director is assisted by a Directorate, an advisory entity with no standards-setting powers. The members of the Security Directorate are as follows. Jeffrey I. Schiller jis@mit.edu Ran Atkinson atkinson@itd.nrl.navy.mil Steve Bellovin smb@research.att.com Steve Crocker crocker@tis.com Barbara Fraser byf@cert.org James M. Galvin galvin@tis.com Phil Karn karn@qualcomm.com Steve Kent kent@bbn.com John Linn linn@ov.com Clifford Neuman bcn@isi.edu Rob Shirey shirey@mitre.org Ted Ts'o tytso@mit.edu In addition to the Directorate, the Security Area is assisted by the Security Area Advisory Group (SAAG). The SAAG is an open group that meets at least once during each IETF meeting as well as electronically via the saag@tis.com mailing list. During the Security Area Advisory Group (SAAG) meeting, the activities of the Security Area, including the Directorate, will be reported and discussed. In addition, the SAAG meeting will provide an opportunity for open discussion of security issues. Included below is a summary from those working groups and birds of a feather sessions with security relevant activities to report and the Security Directorate meeting summary. In addition, the following topics were discussed during the SAAG meeting. New Call for Action Jeff Schiller reported that the Router Requirements Working Group has been resurrected. The version of the document that has been languishing for years has been published and designated Historical. Fred Baker has volunteered to edit a new version of the document which has been posted and is currently being discussed. Volunteers are needed to give the document a security review. It was noted that the document is just over 200 pages, so its review would require a serious commitment by one or more people. Interested individuals are asked to contact Jeff Schiller directly. Telnet Encryption Option At the last IETF, it was agreed that a document should be produced specifying the existing practice. However a serious vulnerability has surfaced in the existing practice. A better version of the protocol is needed. The Security Area Director will work with the Applications Area Director to create a design team and/or working group to tightly focus on getting a better version of the Telnet Encryption Option documented. Key Management At the last IETF, it had been agreed that a key management working group would be created. However, since that time, the IPSEC Working Group has a proposal for a session key establishment protocol. Therefore this action item has been overtaken by events. On a more specific topic, key generation is a hard problem. It is easier than most people realize to have poorly chosen keys. As a topic for further discussion, Jeff Schiller suggested that perhaps the security area should consider favoring protocols that generate keys on key distribution centers. Other Jeff Schiller closed the meeting by asking for opinions about the IETF meeting structure, e.g., meeting at night and whether technical presentations should be continued or reduced. He also gave a brief overview of the IETF/IESG process and reminded everyone about the IETF Web Pages -- http://www.ietf.cnri.reston.va.us -- which include pointers to all working groups, RFCs, Internet-Drafts, charters, mailing lists and mailing list archives. The activity of the following working groups and birds of a feather sessions was reported. HyperText Transfer Protocol Security BOF (HTTPSEC) The purpose of the BOF was to discuss providing security services for the HTTP/WWW suite. It began with a presentation of Secure HTTP. The consensus was to charter a working group to continue the work. The group drafted a charter and used its remaining time to discuss requirements. Object/Document Security BOF (IOS) The purpose of the BOF was to discuss adding security to documents and ``static'' objects. Several alternative technologies were presented. The consensus was to create a working group to continue the work. A charter will be drafted and a discussion of requirements will continue on a mailing list to be created. Authenticated Firewall Traversal Working Group (AFT) This newly chartered working group met for the first time at this IETF. Its principal task is to standardize SOCKS. At this meeting, extensions to support UDP and authentication were discussed, including whether AFT or IPSEC should provide this technology. No conclusion has been reached yet. Common Authentication Technology Working Group (CAT) The CAT Working Group discussed issues related to the following Internet-Drafts: Kerberos One-Time Passwords, Simple Public-Key Mechanisms (SPKM), draft update to RFC 1508, Windows GSS-API bindings, Interoperable Object Protection (IOP), FTP Security, and multiple overlay proposals for interfaces to layer atop GSS-API. Revised Internet-Drafts are expected for many of these documents before the next IETF. In particular, a revised FTP authentication specification is expect to be submitted for publication as a Proposed Standard by the next IETF. Also, depending on implementation experience, a version of the SPKM draft may also be submitted for advancement. Domain Name System Security Working Group (DNSSEC) Consensus was reached that the working group should proceed with the Eastlake/Kaufman proposal. Some issues were discussed and a revised specification is expected shortly. Depending on implementation experience, the proposal may be submitted for publication as a Proposed Standard prior to the next IETF. IP Security Working Group (IPSEC) Significant progress was made during this IETF: there appears to be rough consensus on the IPSP protocol. There were several key management alternatives presented but all participants are willing to work together to arrive at a consensus proposal that meets the requirements of the working group. In addition, we believe that all known patent issues have been resolved. The mailing list will be used to continue the discussion of the requirements and how the proposals address them. Privacy Enhanced Mail Working Group (PEM) The consensus of the working group was to submit the MIME-PEM integration documents for publication as Proposed Standards. A Last Call will be issued on the mailing list to allow folks not in attendance to comment. The Security Area Directorate met on Monday afternoon for a 2 hour meeting. The following actions were adopted. Keyed MD5 Ran Atkinson reported on a vulnerability in using keyed MD5 that had been brought to his attention. Since several protocols are considering using keyed MD5 -- SNMPv2 already does -- Jim Galvin volunteered to document the issues in an Informational RFC. Randomness Document A revised document discussing randomness issues has been prepared and will soon be published as an Informational RFC.