From saag-request@neptune.tis.com Fri Sep 1 19:09:55 1995 Received: from TIS.COM (neptune.tis.com [192.94.214.96]) by postman.osf.org (8.6.9/8.6.x) with SMTP id TAA08164 for <rsalz@osf.org>; Fri, 1 Sep 1995 19:09:54 -0400 Received: from neptune.tis.com by neptune.TIS.COM id aa06599; 1 Sep 95 16:20 EDT Received: from relay.tis.com by neptune.TIS.COM id aa06595; 1 Sep 95 16:18 EDT Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (g3.0.1) id xma004617; Fri, 1 Sep 95 16:07:54 -0400 Received: by big-screw id AA23873; Fri, 1 Sep 95 16:18:03 -0400 Date: Fri, 1 Sep 95 16:18:03 -0400 Message-Id: <9509012018.AA23873@big-screw> From: "Jeffrey I. Schiller" <jis@mit.edu> Sender: jis@mit.edu To: minutes@cnri.reston.va.us Subject: IETF Security Area Report (July 17-21, 1995: 33rd IETF meeting) Cc: secdir@TIS.COM, saag@TIS.COM Status: R
-----BEGIN PGP SIGNED MESSAGE----- IETF Security Area Report Jeff Schiller and Jim Galvin jis@mit.edu galvin@tis.com July 17-21, 1995 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. Send a message to the address saag-request@tis.com to join the list. During the Security Area Advisory Group (SAAG) meeting, the activities of the Security Area, including the Directorate, are reported and discussed. In addition, the SAAG meeting provides 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. o Documents Approved as Proposed Standards The IESG approved the advancement of five of the IPSEC documents to proposed standards. With the advancement of these documents the IPSEC working group will focus on issues related to key management. The IESG approved the advancement of the two MOSS documents to proposed standards. With the advancement of these documents the PEM working group has completed its charter and will be closed. o Domain Name System Security The last revision of the enhancements for the DNS to support security has been released. It will enter working group last call very soon; no issues are expected to be raised. At the end of the working group last call the document will be submitted to the IESG to be considered for publication as a Proposed Standard. An implementation of the specification is available to U.S. and Canadian sites and individuals via anonymous FTP (see ftp://ftp.tis.com/pub/DNSSEC/README for details). o Key Management It was noted that the Internet needs two kinds of key management: one for short-term keys and one for long-term keys. The expected usage of short-term keys would be on a per connection or per message basis. Long-term keys, on the other hand, would probably be used to exchanged short-term keys. The distribution and management of long-term keys requires the existence of a global infrastructure. There are two options for the global infrastructure today: Secure DNS or The Directory (X.500). It is also possible that something completely different will be needed and developed. Key management is expected to get increasing attention in the IETF. o Internet Security Architecture Steve Crocker gave an abbreviated version of his presentation to the IAB the previous evening. He posed a challenge to the community to improve the network security at IETF meetings. The specific proposal is to have IPSEC available with manual keying, which would be enough to make a difference when compared to the current configuration. This should be available for use in the IETF terminal room by both the terminals/workstations and laptops. In addition, we should install a demonstration firewall that is IPSEC friendly. The goal is to make it available at the next IETF meeting in Dallas (December 4-8, 1995). The activity of the following working groups and birds of a feather sessions was reported. o Secure Socket Layer (SSL) BOF A consensus developed for the need for a session layer security protocol. This was predicated on observing that IPSEC is below the transport layer and the session layer is above it, and that implementing security in the transport or network layer would require changes to operating systems. In contrast, session layer security could be implemented and added non-invasively to existing systems, thus making security services available to a broad range of application protocols. As a result, a working group called Session Layer Security will be proposed. The Secure Socket Layer specification will serve as the starting point for the new working group. o Internet Secure Payments Protocol (ISPP) BOF This BOF met two times with more than a dozen technology presentations. Fortunately, the various technologies are much more similar than they are different. The consensus was that the IETF should have one or more working groups in this area. Charters will be proposed and submitted to the area director for consideration. o Simple Key Management for IP (SKIP) BOF SKIP is Sun's proposal for key management on the Internet. It is a competitor to the Photouris specification being discussed in IPSEC. It is still undecided as to whether this specification should be discussed as part of the IPSEC working group or within its own working group. Although there appeared to be consensus to move the SKIP specification onto the standards track, the authors will need to discuss the process and relationship to IPSEC with the area director and the Chairs of the IPSEC working group before this can be done. [Note: Since the IETF meeting took place discussions between the various parties are proceeding. The likely outcome will be for the SKIP work to take place within the IPSEC working group.] o Authenticated Firewall Traversal (AFT) There are currently four implementations underway with interoperability testing expected to begin shortly. If the testing is successful three documents will be submitted to the IESG to be considered for publication as Proposed Standards before the next IETF meeting in Dallas. o Common Authentication Technology (CAT) The CAT working group discussed topics related to active documents, including GSS-V2 (to receive another set of specific revisions at the Internet-Draft level, and then to be recommended for advancement to Proposed Standards), IDUP (where revised interface specifications and a new mechanism specification were discussed, with standards advancement to be considered at the Dallas IETF), GSS-API Negotiation (new draft discussed), Kerberos mechanism and extensions (status and comments discussed, new drafts to follow), FTP Security (to be recommended for advancement to Proposed Standard after inclusion of clarifying revisions), and a presentation of a new mechanism based on FIPS PUB JJJ cryptography. Presentations on work in progress included GSS-API integration into World-Wide Web browsers and servers, loadable GSS-API multi-mechanism support, and discussion of the use of RFC-1731 as a generic framework for integration of security tokens into text-based applications. The group also discussed a range of candidate follow-on topic areas related to authorization, and identified a subset with apparent common value and feasibility for proposals and work by group members. o Web Transaction Security (WTS) There were three short presentations on related subjects and a review of the two documents being developed by the working group. With respect to the requirements specification, several new issues were raised at this meeting and most, but not all, were resolved. There was consensus to resolve the remaining issues on the list and then submit the document to the IESG to be considered for publication as an information RFC. Recent changes to the SHTTP document were reviewed and no objections were raised. An outstanding issue is coordinating SHTTP with MOSS, which is dependent on the harder (and outside our scope) problem of coordinating HTTP with MIME. We remain hopeful that we will reach consensus on a document to propose to advance to Proposed Standard by the next IETF meeting Dallas. o IP Security (IPSEC) The interoperability testing of the recently approved Proposed Standards was discussed. The majority of the meeting was devoted to discussing Internet key management and the two working documents on Photouris and ISAKMP. o Site Security Handbook (SSH) Two documents are expected to be available by the first week of November, which will allow for final revisions to be proposed during the next IETF meeting in Dallas followed by advancing the documents onto the standards track as quickly as possible. The Security Area Directorate met on Monday afternoon for a 2 hour meeting. In addition to all of the above, the following was noted. o Intellectual Property Rights (IPR) The purpose of the discussion was information exchange. Several protocols are pending in the IESG as a result of unresolved IPR issues and several protocols from the security area are about to be submitted to the IESG with unresolved IPR issues. It is uncertain exactly what the outcome will be of any specific case. o Key-ed MD5 Key-ed MD5 is being used in a variety of protocols for authentication. The IETF needs an applicability statement which includes advice on how often to change the secrets. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEdqFMUtR20Nv5BtAQELhwP/eTwVc+07AA19P0Q7KdfHxTAaNjnsPBRY 4bb2ekatHDaL5oVH2bbad1DECgOVU2Y0tKBXBNO3Pw1vQiMOV874ZeMIWNtcuxJE MUcd9PLXekRoIUGmUdQMdnVhGEhb4NWPAi6KXzkWRxLN0wZNG9tyjkb7qLCo0dLe +98gDe4dO1c= =2CtY -----END PGP SIGNATURE-----