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@cybercash.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 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. Encapsulating Security Payload IPv6 requires security, specifically that authentication and encryption be available at all times and that authentication be turned on by default. This decision received considerable attention at the open IESG meeting held after this SAAG meeting. Jeff Schiller conducted a number of straw polls to assess some measure of the community during this meeting. In particular: o Should we require ESP or recommend it? The overwhelming response was to require it. o (1) Should we require ESP and DES or (2) should we require ESP but leave DES optional or (3) should we leave ESP optional but if you do it use DES or (4) should we leave ESP optional and leave DES optional? The overwhelming response was in favor of requiring both ESP and DES (1); a number approximating 25% of that response was in favor of the third option. o Should we allow other transformations in addition to requiring DES? The overwhelming response was in favor. The activity of the following working groups and birds of a feather sessions was reported: Common Authentication Technology Working Group (CAT) The working group charter is being revised to include scope compatible with Independent Data Unit Protection (IDUP) and with future authorization support facilities. The following documents are eligible for the issuance of a working group last call (as indicated) in advance of their submission to the IESG for publication as Proposed Standards. o The FTP Security specification has been resurrected with a new editor, March Horowitz. A revised specification is expected to be available soon. o A revision of Version 2 of the GSS specification and C bindings documents is expected to be available soon. The Simple Public Key Mechanism is considered stable at this time, pending resolution of an identified issue concerning X9.44 replay protection, and was placed in working group last call on 5 April 1995 in advance of its submission to the IESG for publication as a Proposed Standard. RFC 1510 (Kerberos) is now eligible for advancement to Draft Standard. One issue is relevant to advancement of the document and will be resolved on the mailing list. A presentation on Secure Socket Layer was given by NetScape. An Internet-Draft is expected to be available soon. Discussion continued on the other documents and activities. Domain Name System Security Working Group (DNSSEC) This working group did not meet at this IETF. Nonetheless, it was reported that a revised specification will be released shortly in parallel with an alpha implementation. A working group last call will be issued as soon as it is released and the document will be progressed to submission to the IESG for publication as a Proposed Standard. Guidelines and Recommendations for Security Incident Processing Working Group (GRIP) Note: GRIP is part of the Operational Requirements Area but is tracked by the SAAG and Security Area. This new working group has drafted guidelines for security incident response teams. A revised draft is expected to be available soon at which time a working group last call will be issued. The document will be submitted to the IESG for publication as a Proposed Standard by the next IETF. IP Security Protocol Working Group (IPSEC) Eight Internet-Drafts were submitted for this meeting. Five of these specifications describe the network layer cryptographic mechanisms and are in working group last call. The working group has reached consensus on requiring the implementation of a hybrid Diffie-Hellman key exchange for the IKMP. The ``Photuris'' specification will be progressed in the working group as the baseline description of this key exchange. Additional presentations were given on possible modifications to the Photuris exchange and on a framework for the IKMP protocol signaling. Privacy-Enhanced Electronic Mail Working Group (PEM) This working group did not meet at this IETF. Nonetheless, it was reported that the latest version of the PEM/MIME integration specification (now called MIME Object Security Services (MOSS)) is waiting for the working group chair to issue a working last call [done as of the writing of this report] and to progress the document to submission to the IESG for publication as a Proposed Standard. Upon publication of the documents this working group is expected to go dormant. Other working groups will be created to address related issues, e.g., the Internet certification hierarchy. Router Requirements Working Group (RREQ) The Router Requirements Working Group has a document ready to be submitted to the IESG for publication as a Proposed Standard. It will include a requirement level of SHOULD for strong remote authentication. An issue to be resolved before the document advances to Draft Standard is the use of security by routing protocols. Web Transport Security A web transport security working group will be formed with Charlie Kaufman as the Chair. It will pickup where the SHTTP BOF from the last IETF meeting left off. Other The Authenticated Firewall Traversal Working Group (AFT) and the S/Key One-Time Password Standardization BOF (SKEY) also met during this IETF. The latter is expected to submit a charter to become a working group by the next IETF; Neil Haller and Ran Atkinson will be co-Chairs. The Security Area Directorate met on Monday afternoon for a two-hour meeting. In addition to all of the above, the following was noted. Audio/Video Transport (AVT) and ONC Remote Procedure Call (ONCRPC) Working Groups Both of these working groups have documents ready for advancement to Proposed Standards. Allison Mankin, the Transport Area Director, has requested a security review of their documents, as follows: draft-ietf-avt-cellb-profile-04.txt draft-ietf-avt-jpeg-01.txt draft-ietf-avt-profile-04.txt draft-ietf-avt-rtp-07.txt draft-ietf-avt-video-packet-04.txt draft-ietf-oncrpc-xdr-01.txt draft-ietf-oncrpc-rpcv2-01.txt draft-ietf-oncrpc-bind-00.txt draft-ietf-oncrpc-auth-00.txt