Editor's note: This report has not been edited. Date: Fri, 5 Aug 94 14:50:43 -0400 From: "Jeffrey I. Schiller" Subject: IETF Security Area Report (8/5/94) IETF Security Area Report Jeff Schiller and Jim Galvin jis@mit.edu galvin@tis.com August 5, 1994 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 Directorate are as follows. Jeffrey I. Schiller Ran Atkinson Steve Bellovin Steve Crocker Barbara Fraser James M. Galvin Phil Karn Steve Kent John Linn Clifford Neuman Rob Shirey Ted Ts'o 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 Directorate meeting summary. The following topics were discussed during the SAAG meeting. o 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 10 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 cleartext passwords and the need for support of authentication and encryption services. o 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. o CAT The CAT WG met for 2 sessions in Toronto. Carlisle Adams (BNR) 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. We reached rough consensus 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 on revision of the Internet Draft against outstanding comments. o IPSEC The IPSEC working group met twice in Toronto. The Wednesday July 27th 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 Thursday 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. o 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 PEM WG meeting, to add examples, and to make the document independent of 1421. The second I-D 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. o 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, we did succeed in at least getting at least a few minutes discussion of all the outstanding issues. The discussion will continue on the mailing list with the objective of achieving consensus on a proposal for DNS security. o MobileIP 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. o TELNET See the Directorate meeting summary below. o TNFS A specification has been submitted and reviewed by Jeff Schiller. As soon as a revision is available it will be published as informational document. o Site Security Handbook A BOF was held this week that generated enough interest to create a working group to revise the existing document, with Barbara Fraser as Chair. It was noted that working group will produce two documents: one directed at system administrators and one directed at end users. Note: 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 2 hour meeting. The following actions were adopted. o TELNET 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 should be resurrected, a section that explains the active attack should be added, and it should be published as an experimental protocol. 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 protocol. When the new proposal is available, it will be advanced on the standards track. o Common Authentication Technology (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. o 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. o PEM/MIME 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 preceeded the PEM Working Group meeting where issues arose requiring additional work by the document editors.] o Domain Name System Security (DNSSEC) This group is making progress at this time so there is no action required from the Directorate. o Site Security Handbook (SSHWG) 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.