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. Security Area Advisory Group (saag) The main bulk of work for this Group 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, Network Management, OSI Integration, Operational Requirements, Routing, Transport and Services, or User Services. 4. Internal 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 Security Area Advisory Group met during the first and last working group period of the Santa Fe IETF. The first meeting is used to coordinate the activities for the week and the second meeting is used to report on the activities that have occurred. During the week, of the twenty-three open work items on Monday, five work items were closed and four new work items were opened. Eight work 1 items received no attention. The key activities for the week to report are all working groups in the Security Area: SNMP Security, Common Authentication Technology, and Privacy Enhanced Mail. SNMP Security (snmpsec) There are three documents which have been reissued. There are four implementations, three of which have been demonstrated to interoperate with each other. The final actions are cleaning up the documents, reviewing them, and submitting them to the IESG for consideration as Proposed Standards. One of the important technical issues to be discussed was the choice to be made between message digests: MD4 and MD5. It is clear that MD5 is the right choice for standards actions or something that you want to invent for some stability. MD5 does run slower by some amount than MD4, but the overall equation makes a fairly modest impact. There will probably be a lot of performance measurements showing up, but it is pretty clear that performance is not the critical issue. This decision effects a number of other working groups, each of which had decided to adopt whatever choice is made by SNMP Security. These include the 822 Extensions and PPP Extensions Working Groups. Common Authentication Technology (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, 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. The feature of the mechanisms currently proposed is they depend upon a global identification scheme, i.e., you have a name that exists outside the context of the machine you are trying to connect from or connect to. The name identifies a set of credentials that area forwarded on your behalf. This raises the question of what happens when there is an application of the technology on a machine on which your credentials do not exist, for example a terminal server at an IETF meeting. Does it makes sense for one of the underlying mechanisms to be the use of passwords? This opened up the discussion in multiple directions, but the critical question is what is the ambition level of the CAT technology, with respect to a much larger set of issues in security, authentication, identification, and in particular with respect to authorization. For now, CAT will continue down the path it is on. There will be subsequent activity to serve these larger functions. There is a set of documents in preparation. Two Internet Drafts exist that describe the interface, a basic functional description, and 2 specific C structures. An Internet Draft exists for each of Kerberos and DASS. Privacy Enhanced Mail (pem) There was a great deal of controversy during the Atlanta meeting, but a number of meetings and interactions have occurred since then, resulting in substantial progress and resolution of major issues. It is worth noting there was a booth and demonstrations at INTEROP, where multiple interoperating implementations were heavily attended during the whole period. It was a big success for everybody. The key decision that came out of the meetings following Atlanta was to open the range of policies. There had been a single policy coming into existence emphasizing very high assurance that the binding of the name and public key in the certificate actually represented a real person and had not been forged. The controversy was focused on whether or not the high assurance was appropriate in all cases. The resolution was to push the notion of assurance down one level in the certificate validation hierarchy and create what are now called Policy Certification Authorities, which are bound together by a policy neutral administrative function called the Internet Certificate Authority. The current candidate policies are a continuation of the high assurance policy, a mid-range policy, some support for residential users, and support for persona users. There will be two bodies of software available. There is an implementation Trusted Information Systems has been developing for some time, that will include modifications to MH and a general purpose filter, which will be distributed in source code form with an object version of the cryptography supplied by RSA Data Security Incorporated (RSADSI). RSADSI will separately make available a limited size tool kit, in source form, on a you-build-it basis. Neither of these is intended for commercial applications. 3