Security Area Director(s): o Steve Crocker: crocker@tis.com Area Summary reported by Steve Crocker/TIS 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 appendix to this report defines what is meant by ``security'' on the Internet. Much of the work of the Security Area is performed in coordination with working groups in other areas. The Security Area Advisory Group (SAAG) is a group of security experts which provides both consulting help to other areas and direct management of working groups within the Security Area. The main bulk of the work for the SAAG consists of a set of formal work items. These work items correspond to working groups within the IETF Security Area, security-relevant developments within working groups in areas other than security, and internal SAAG work items which do not merit the creation of formal working groups but which do need some level of attention. Below is the status of each of the working groups officially chartered or initiated within the Security Area. Immediately following those reports is an update on other security issues as well as security related work in other IETF areas. Authorization and Access Control Working Group (AAC) The AAC Working Group met on Wednesday afternoon. The need for demonstrations of the technology was discussed; possible applications for an authorization API include Prospero, remote execution, database access, and file transfer. The representation of authorization information for access control lists and distributed authorization credentials was discussed. There was some contention on this topic. At the SAAG meeting is was suggested that some of the work arising from this working group may be best addressed initially by the PSRG. Cliff will follow-up on this. Common Authentication Technology Working Group (CAT) The CAT Working Group met for two sessions at the Amsterdam IETF, discussing (in about equal proportion) general CAT issues and FTP security integration. We reviewed the status of implementation and specification activities, identified items requiring follow-up work, and managed to associate individuals and subset groups with several of the desired items. The GSS-API base specification, GSS-API C Language Bindings, and Kerberos Version 5 documents have been submitted, adopted, and published by the IESG as Proposed Standards. The DASS document has been submitted, adopted, and published by the IESG as an Experimental Protocol. Commercial Internet Protocol Security Option Working Group (CIPSO) There is a new draft of the CIPSO specification; Steve Crocker will make sure it gets published as an Internet-Draft. There are several folks who are unsatisfied with this document, including both SAAG and PSRG members. There has been some difficulty getting the issues communicated effectively to Ron Sharp. Steve Crocker has been tasked with resolving the conflicts. Internet Protocol Security Protocol Working Group (IPSEC) The meeting was opened by Al Hoover with an introduction to the IPSEC Working Group for first time attendees, a review of the approved IPSEC charter, a review of liaisons between IPSEC and IPng, IEEE, CAT, and other working groups. A brief discussion of preliminary implementations related to IPSP was discussed. Absences of IPSEC implementors limited the scope to a review of the various approaches (SwIPe, NLSP, SP3). IPSEC would like to target demonstrations of preliminary implementations (non-interoperable) for the Houston (November) IETF. Demonstrations of preliminary interoperable implementations is targeted for the March IETF. Network Access Server Requirements Working Group (NASREQ) The NASREQ Working Group meeting was sparsely attended on Thursday morning. Lacking critical mass, there was little discussion about any of the outstanding issues. The modified charter and schedule was reviewed. The chair requested volunteers to help write sections of the draft. (One person expressed willingness to help, provided he received approval from his management.) Representatives from the ACCT Working Group and the AAC Working Group requested more contact and information flow between the groups. Privacy-Enhanced Electronic Mail Working Group (PEM) The PEM Working Group met for one, 2-hour session on Wednesday afternoon. The meeting opened with reports on implementation status from seven PEM developers, representing commercial, research, and academic communities. Next, the meeting addressed the continuing topic of MIME-PEM integration. No substantive progress was made on this topic, due to a lack of written submissions for review prior to the meeting. Nonetheless, there was a discussion of this topic, based on a very recent discussion between two of the authors of the relevant Internet-Draft. A presentation on the use of Distinguished Names versus Domain Name System names in certificates followed, but was truncated because of time limitations. A presentation on the rationale for the current certification system design was skipped, also due to time constraints. Full text of the slides for both of these presentations will be included as an appendix to the meeting minutes. The meeting concluded with a discussion of triple-DES modes of use for PEM, and a paper exploring this issue was distributed at the meeting. While there was substantial sentiment for one of the modes, it was agreed that further analysis is called for. SNMP Security Working Group (SNMPSEC) In conjunction with the SNMPv2 Working Group, twelve documents have been completed and published as Proposed Standards. This work item was officially closed at the Amsterdam IETF. TELNET Working Group (TELNET) - Applications Area There is no security-relevant progress to report from the Amsterdam IETF. Router Requirements Working Group (RREQ) - Internet Area The previous single document has been split into four documents and a number auxiliary documents. Phil Almquist has responsibility for finishing the documents and submitting them to the IESG for publication. Domain Name System Working Group (DNS) - Service Applications Area A mailing list and subcommittee of the DNS Working Group has been created. Work on DNS security is expected to begin on the mailing list. Trusted Network File System Working Group (TNFS) - Service Applications The TNFS Working Group meets principally under the auspices of the Trusted Systems Interoperability Group. No progress to report. Audio/Video Transport Working Group (AVT) - Transport Area This activity was to be reviewed to identify the security issues for the Amsterdam meeting. No progress to report. Integrated Directory Services Working Group (IDS) - User Services Area Privacy constraints exist for the data, but there was no substantial discussion at this time. Export Control Issues Vint Cerf and Steve Crocker need to press forward on drafting a document. IP: The Next Generation A plan for processing a security review of the competing next generation proposals were to be drafted for the Amsterdam meeting. No progress to report. IRC A document in RFC format exists that purports to document this protocol. At this time, this work item exists to track this activity. ITAR Publication An on-line version of the US International Traffic in Arms Regulations (ITAR) will be created as soon as it has been published in the Federal Register, probably as an informational RFC. Key Management Strategies A review of key management strategies and activities was to be drafted for the Amsterdam meeting. No progress to report. At the SAAG meeting it was asked why this work item is called out separately from the IP security work item. John will be asked to address this question in his draft. Mobile IP Security John Ioannidis was to report on the relationship between this work item and the IP security work item at the Amsterdam SAAG meeting; he was not present at this meeting. Al Hoover will follow-up with John on the status of this work item. Random Number Generation Issues A revised Internet-Draft is overdue. Jeff Schiller will follow-up with Don Eastlake to arrange a new draft. Routing Security Plan No progress to report. Steve Crocker will follow-up with Radia Perlman. Security Area Architecture Included at the end of this report is a copy of the summary description of the security area in the IETF. Working Group Liaison Checklist A checklist was prepared and distributed at the SAAG meeting. A copy will be distributed to the SAAG Interest mailing list for discussion. APPENDIX The Security Area Steve Crocker The Security Area is concerned with the addition of security services throughout the Internet protocol stack and throughout the Internet itself. The term "security" covers a handful of interrelated concepts. In broad terms, the concept means protection against unauthorized actions of others. In the Internet community, we're concerned with at least the following forms of security. Confidentiality: Protection of information against unauthorized disclosure. For information that is in transit across the Internet, this means making sure that only the intended recipient(s) see it. Integrity: Protection of information against tampering. For information in transit across the Internet, this means making sure that the receiver gets what was sent, or at least knows whether the data that arrives is in fact a true copy of the data that was sent. Authentication: Verification of the identity of the parties involved in a transaction. In Internet transactions, this means providing assurance that the identification of the sender is correct and has not been forged, and that the actual recipient is the one(s) that the sender specified as the authorized recipients. Access Control: Control over who is allowed to access or use various resources. This list is not complete. Security is a broad term and covers an open-ended list of services. Another dimension to security is who is being protected from whom? A network, for example, is obliged to provide some degree of protection to its customers. It may promise its customers that it will not tamper with nor disclose user information while that information is within its perimeter. In this case, the network is providing protection to the users, and the users will either trust or not trust the network to provide this form of protection. At the same time, the network needs to be protected from damage, disruption or penetration by users. Thus the network operator is also interested in assurance that his assets are protected against undesirable acts by the users. Because security cuts across all layers in the protocol stack and hence affects all areas, the work of the Security Area includes both the development of protocols within the Area and the assistance of working groups in other areas. The Security Area Advisory Group (SAAG) functions as the Area's internal advisory group, much like a directorate, and also serves as a source of experts to provide guidance and participation in other areas.