Security Area Director(s): o Steve Crocker: crocker@tis.com Area Summary reported by Steve Crocker 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. 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 work for the SAAG consists of a set of formal work items. These work items correspond to four types of activities. 1. Working groups within the IETF Security area. These are marked as ``Security.'' 2. Working groups in allied organizations that function as part of the IETF Security area. These are marked either ``PSRG'' for the Privacy and Security Research Group, or ``TSIG'' for working groups within the Trusted Systems Interoperability Group. 3. Security relevant developments within working groups in areas other than security. These are marked according to the relevant area, viz., Applications, Internet Services, Management, OSI, Operations, Routing, Standards, or User Services. 4. Internal SAAG work items. These are topics which do not merit the creation of a formal working group but which do need some level of attention. These are assigned to a SAAG member and followed for one or more SAAG meetings. These are marked as ``SAAG''. The SAAG met during the first and last working group period of the San Diego IETF. The first meeting was used to coordinate the activities for the week and the second meeting was used to report on the activities that have occurred. During the week, of the twenty-two open work items on Monday, two work items were closed and two new work items were opened. The key activities for the week to report are working groups and work items in the security area: SNMP Security, Common Authentication Technology, Privacy Enhanced Mail, RFC 931 Revision, and Architectural Discussions. 1 SNMP Security Working Group (SNMPSEC) There were three documents, published in January 1992, which are currently under consideration by the IAB. Common Authentication Technology Working Group (CAT) The basic idea is you have a set of applications that want access to one or more authentication mechanisms, for example Kerberos or the Distributed Authentication Security Service (DASS). There is a common program interface, a General Security Services Application Program Interface (GSS-API), that has been defined such that these applications can be written to be neutral with respect to which mechanism is actually employed. The binding with a mechanism takes place at some later time, currently compile time. This raises the question of how two applications each bound to a different mechanism would interoperate. In particular, if one peer supported Kerberos and the other peer DASS, would they be able to authenticate each other? This question was the principal focus of the meetings during this week. Although the GSS-API was not designed with hybrid/common mechanism in mind, it was discovered that it would support such an objective through a number of different technical solutions. Most of the meeting time this week was spent identifying the requirements of a solution. It is believed that the objective is both technically feasible and achievable. Privacy Enhanced Mail Working Group (PEM) The specification of the key management infrastructure has been the principal source of controversy during the last few meetings. A revised document was prepared and distributed prior to this meeting, and was well received during this meeting. Along with the three other documents associated with PEM (Message Encryption and Authentication Procedures; Algorithms, Modes and Identifiers; Key Certification and Related Services), it will be submitted to the IESG by June in hopes of achieving publication as a Proposed Standard by the Boston IETF. The publication of the documents stabilizes the specifications and sets the stage for the deployment of the Internet reference implementation of PEM. A set of action items predicating the deployment of PEM were identified and assigned. These items include establishing the necessary database mechanisms and software at the Internet Certification Authority (ICA) for resolving distinguished name conflicts (this is necessary in the absence of Directory Services), drafting an agreement to be used between the ICA and the Policy Certification Authorities (PCA), and facilitating the creation of PCAs (only one PCA proposal has been submitted to the ICA for review; others are expected soon). All of these items are non-technical and do not effect the publication of the specifications nor Beta testing the deployment of PEM, which is expected to begin soon. 2 RFC 931 Revision RFC 931 is a specification of a protocol for a receiving peer of TCP connection request to ask a server on the originating host of the originating peer for an identifier associated with the originator of the request. The identifier would typically be the login name of the user initiating the request. This protocol was called an authentication server. As far as security is concerned, the value returned by the server is only meaningful in the context of that host, and is informational only since there are no assurances that a valid value is being returned. There is an effort to revise the document to tighten up the syntax of the protocol and put it on the standards track. In addition, a public domain implementation exists that is currently being used by a modest number of sites. Previously this effort was being led by Dan Bernstein, the author of the revised document and the implementation. In order to give the protocol the discussion it needs the effort has been restructured and a working group created with Mike St. Johns as the Chair, the author of the original RFC 931. In addition the revised protocol has been renamed to be called the Identity Server to better reflect its functionality. Architectural Discussions The SAAG in its two meetings spent a significant about of time discussing a security architecture for the Internet. Since the Privacy and Security Research Group (PSRG) is currently addressing the long-term objective(s) in this area, the majority of the discussion focussed on what the SAAG role could be in this area. A number of action items were identified as a result of these discussions. First, Barbara Fraser from the CERT has agreed to draft a document identifying some near-term security goals that the IETF, in particular the SAAG, could be concerned about. This will help to focus SAAG discussions and guide interactions with working groups in other areas. We expect to have the document in time for discussions at the Boston IETF SAAG meeting. Second, two Birds of a Feather sessions will be scheduled at the Boston IETF. One will be for Lower Layer Security and it will probably focus on IP layer authentication and encryption, although some discussion about the OSI TLSP and NLSP, and the SDNS SP3 and SP4 is expected. The other BOF will be to discuss access control. Given the existence of authentication, in particular the strong authentication work of the CAT Working Group, the next question is what to do with the knowledge that you know who your peer is. Finally, the routing area has received very little attention from security to date. With all of the activity in routing it has become essential that the Security Area become much more directly involved. 3 Radia Perlman will be the liaison to the SAAG for the routing area. We will be discussing a routing area security plan during our Boston meeting. 4