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. During the Security Area Advisory Group (SAAG) meeting Jeff Schiller announced the creation of the Security Area Directorate. The directorate will assist the area director as needed, including considering the strategic evolution of security in the Internet, providing security-specific architectural and engineering guidance to working groups and reviewing Internet-Drafts. It is an advisory entity and has no standards-setting powers. The members of the Security Area 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 During the 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 with security-relevant activities to report and the Security Area Directorate meeting summary. The following topics were discussed during the SAAG meeting. Security Area Vision Jeff Schiller volunteered to do the first draft of a Security Area Vision. It will be short (perhaps 2-4 pages) and will provide a first cut at defining a common vision of how security technology will evolve on the Internet. The SAAG will contribute to this vision, and when it is complete, it will be published as an Informational RFC. Jeff started a discussion of the contents of the vision by suggesting that the DNS solved the naming problems of the Internet. This prompted a great deal of discussion that surfaced all the usual issues, including management, usability, and the fact that the DNS is not the only kind of name space. Steve Bellovin was quick to point out that in spite of whatever perceived shortcomings may exist in the DNS, the Internet has ten years of operational experience with it; we should be very careful about suggesting any replacements. There was consensus that support for globally unique names in the Internet was required. Other issues for inclusion in the vision include the realization that the Internet today is vulnerable to significant security attacks, including passive attacks that have been recently referred to as ``sniffer'' attacks. This realization will inevitably lead to the elimination of the use of clear-text passwords and the need for support of authentication and encryption services. FNC Security Council Jeff Schiller reported that Dennis Steinhauer and Steve Squires, representing the FNC Security Council, have proposed a security policy for the Internet. Jeff will get it distributed to the IETF community for review. The activity of the following working groups was reported. Common Authentication Technology Working Group (CAT) The CAT Working Group met for two sessions in Toronto. Carlisle Adams gave a presentation on his Simple Public-Key Mechanism (SPKM) proposal, a GSS-API mechanism being developed based on public-key technology and offering 2-way and 3-way authentication exchange variants, generalized use of OIDs for flexibility, parameter negotiation, and provision for non-repudiation services. Rough consensus was reached on outstanding issues of GSS-API buffer sizes, continuation processing of long messages (not accepted), and context expiration (for K-V5, hard expiration not to exceed supporting ticket lifetimes), pending review on the mailing list. Advancement of FTP security is pending revision of the Internet-Draft against outstanding comments. Domain Name System Security Working Group (DNSSEC) This meeting was dedicated to a discussion of the differences between the two proposals under consideration: Eastlake/Kaufman and Ohta. Although no consensus was reached on any of the issues, there was at least a few minutes discussion of all of the outstanding issues. The discussion will continue on the mailing list with the objective of achieving consensus on a proposal for DNS security. Internet Protocol Security Protocol Working Group (IPSEC) The IPSEC Working Group met twice in Toronto. The first meeting focused on the definition of a cryptographic security protocol to protect client protocols of IP. Several implementations of network layer cryptographic security were discussed. Formats and features of various specifications and proposals were compared (SP3, NLSP, I-NLSP, swIPe). The working group has declared rough consensus on a protocol format based on the consolidation of ideas from several experimental implementations. The IP Security Protocol (IPSP) has been designed to protect both IPv4 and IPng. Additional investigation of ``authentication-only'' services for IPng require additional investigation. These IPng services support the examination of ``protected'' information by intermediate systems. A draft of the new IPSP specification is scheduled for the next IETF meeting. During the second meeting the requirements and possible mechanisms for the Internet Key Management Protocol (IKMP) were discussed. The IKMP work is focused on the support of IPSP, not on key management in general. A draft of IKMP is scheduled for release prior to the next meeting. Additional work beyond the specification of IKMP is required to coordinate the relationship of certificates and naming hierarchies to the various Internet security mechanisms. Privacy-Enhanced Electronic Mail Working Group (PEM) The major focus of this meeting was review of two recent Internet-Drafts: ``Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted'' and ``PEM Security Services and MIME.'' The first document, when stripped of those portions that the authors now deem PEM-specific, will be quite brief. The second document requires considerable editing to address a number of issues raised during the meeting, to add examples and to make the document independent of RFC 1421. The second Internet-Draft has addressed the major canonicalization problems that plagued forwarded authentication in previous drafts, but some details remain to be resolved. There was considerable debate over proposed name forms and unification of originator and recipient ID formats, and work will be required by the authors to address the concerns cited. Minor issues relating to the syntax for certificate lists, requirements for separate signature and encryption certificates, etc., seem easier to resolve. Trusted Network File Systems Working Group (TNFS) A specification has been submitted and reviewed by Jeff Schiller. As soon as a revision is available it will be published as an Informational RFC. TELNET Working Group (TELNET) - Applications Area See the directorate meeting summary below. IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) - Routing Area This group has not resolved the choice of using nonce- or timestamp-based authentication. They have adopted the use of MD5 and are using manual key distribution, for now, due to the lack of a key management system. Site Security Handbook BOF (SSH) - User Services Area A BOF was held this week that generated enough interest to create a working group, chaired by Barbara Fraser, to revise the existing document. It was noted that the working group will produce two documents: one directed at system administrators and one directed at end users. Although the Site Security Handbook is a security-related document, the working group will exist within the User Services Area. The Security Area Directorate met for the first time on Monday afternoon for a two hour meeting. The following actions were adopted. Common Authentication Technology Working Group (CAT) The draft FTP security specification had been submitted for review prior to publication. Jeff Schiller reviewed the document and provided comments back to the editor. As soon as the editor revises the document it can be resubmitted for publication as a Proposed Standard. Domain Name System Security Working Group (DNSSEC) This group is making progress at this time, so there is no action required from the directorate. Privacy-Enhanced Electronic Mail Working Group (PEM) A final review of the PEM/MIME integration specifications is expected during this week's PEM meeting. Priority should be given to finding the shortest path possible to publication of these documents as Proposed Standards, which have been subject to many revisions over the last year. After the documents have been submitted and accepted for publication, the charter of this working group will be reviewed. [Note: This discussion about PEM/MIME preceded the PEM Working Group meeting where issues arose requiring additional work by the document editors.] TELNET Working Group (TELNET) - Applications Area What is the status of the TELNET authentication and encryption options? It was reported that there exists a draft specification of each option and an implementation. However, the current encryption option is vulnerable to an active attack. A new draft incorporating both authentication and encryption that is not vulnerable to an attack has been proposed but has not been forthcoming. The problem is that other folks are implementing the draft encryption option in spite of its vulnerability. The TELNET Working Group is languishing due to the lack of time available from the current chair. Also, no one has volunteered to update the currently available implementation to include the proposed changes to protect against the attack. While the Applications Area sorts out the status of the TELNET Working Group, it was suggested that the existing encryption option specification be resurrected, a section that explains the active attack should be added and it should be published as an Experimental RFC. Ted Ts'o has agreed to resurrect the specifications and Jeff Schiller will write the caveat about the active attack. The document will then be submitted for publication as an Experimental RFC. When the new proposal is available, it will be advanced on the standards track. Site Security Handbook BOF (SSH) - User Services Area There is a BOF this week to resurrect the Site Security Handbook and create a working group to revise it. No directorate action is required at this time. Key Management Key management is an issue that surfaces in many working groups and is not receiving sufficient attention within the IETF. We agreed to create a working group to address key management. Steve Bellovin has volunteered to chair the working group and Ran Atkinson agreed to create the first draft of the charter. It was noted that there has been progress licensing public key technology (RSAREF in particular) for use in IPSEC and DNSSEC.