Security Area Director: 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. 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 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. Following the SAAG minutes is a status report for 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. Security Area Advisory Group (SAAG) During the monday afternoon meeting, Steve Crocker led a discussion on Internet security architecture issues. Topics included application support for security, transport/network layer support for security, identification of zones of trust, and firewalls. The discussion included the following points. o Are firewalls the best (or at least one of the best) approaches to security? Consider that applications today expect to be end-to-end, i.e., in general they are not firewall friendly. If firewalls are a direction of the IETF/Internet, then there should be a statement of this principle so that we build all future protocols with it in mind. o The PSRG is working on a security architecture document. It explicitly addresses end-to-end security services and mechanisms, while a hybrid approach involving firewalls appears to be more common. In any case, a discussion of firewalls would be useful. o Firewalls were compared to the installation of burglar alarms in homes. In particular, most people install alarm systems in response to a burglarly, as opposed to installing them as a preventative measure. Is it possible that if environments (or protocols) protected themselves they might not need a firewall? Firewalls are a ``convenient'' security measure to install in the short-term. In addition to the architecture discussion, Steve Kent presented a status of the PSRG security architecture document, Bill Simpson expressed a desire for additional authentication mechanisms in PPP, in particular Kerberos, and it was noted that although Triple-DES will be discussed within the PEM working group, it is applicable in many contexts and may need broader exposure. Authorization and Access Control Working Group (AAC) The AAC Working Group discussed a revised framework for representing privilege attributes and restrictions for distributed authorization credentials and access control list entries. The new framework addressed concerns raised at the Amsterdam IETF. Attributes are now assigned to one of three classes: privilege attributes, restrictions, and aggregates. The contents of the security context used as input to the authorization API was discussed next. The security context should be filled in initially by the authentication mechanism (e.g., GSSAPI) and might be subsequently augmented by other security mechanisms. The security context could include verified authentication and authorization information, and might separately specify unverified information and delegated credentials. The form of the arguments and return values of the authorization API was discussed next and will be further refined. To close, the group discussed the drafting of a document to provide network application developers with guidelines for supporting authorization in their systems. Common Authentication Technology Working Group (CAT) The CAT Working Group met for two sessions in Houston. The status of ongoing activities was reviewed, including a reworked GSS-API implementation for Kerberos V5 beta 3; this implementation, and an Internet-Draft describing its GSS-API mechanism characteristics and token formats, are scheduled to become available later this year. Some interface clarifications and extensions (e.g., a new GSS_Inquire_context primitive) were discussed as inputs to Internet-Draft successors to RFCs 1508/1509, targeting inclusion in eventual Draft Standard versions to supplant those RFCs and comprise a ``Version 2'' GSS-API. Related topics to be discussed further on the mailing list include multi-mechanism credential management and error reporting. Piers McMahon gave a presentation on SESAME's multi-mechanism implementation, and distributed a paper for comment. Sam Sjogren and Steve Lunt led a discussion on the FTP Security Internet-Draft, to be updated shortly and to be used as the basis for an interoperability test (using Kerberos V4 technology) planned for March 1994. Representatives from the NASREQ Working Group described their currently-contemplated architecture, as input to determining how the CAT Working Group and technology might support their needs. Ran Atkinson gave a presentation on the Internet Authentication Guidelines Internet-Draft, receiving and soliciting comment from the working group. Internet Protocol Security Protocol Working Group (IPSEC) There are several known experimental implementations of IP Security, two of which demonstrated their approach during the Houston IETF. Demonstrations of preliminary interoperable implementations is targeted for the next IETF. Key management is still an open issue. The implementations include: o I-NLSP - Rob Glenn o swIPe - Phil Karn o KeyRing - Rob Hagens o TANDU/Cryptonette - Charlie Kaufman o LAN Guardian - Mike O'Dell o SP3 - Paul Lambert Jim Zmuda and Phil Karn gave demonstrations of their implementations. Jim's implementation was based on the ISO 11577 specification for Network Layer Security Protocol (NLSP) and used the NLSP specification of a Security Exchange Protocol (SAEP) for key management. The implementation demonstrated by Phil Karn was based on Phil's KA9Q software running on a portable computer (80386 based). This demonstration ran between Houston and Phil's home. Key management was based on the manual entry of DES key variables. Network Access Server Requirements Working Group (NASREQ) A very brief presentation of distributed authentication was presented as a possible future subject for the working group to consider. The possibility of changing the charter was discussed, and the following elements were described as a possible direction: o Finish the NAS Requirements document and submit it for consideration as an Informational RFC following the Seattle IETF. o Revise the RADIUS protocol definition and submit it for consideration as an RFC after review at the Seattle IETF. o Move KAP/PKAP to the Point-to-Point Protocol Extensions Working Group (PPPEXT) and/or to a working group in the Security Area. o Focus the attention of the group on distributed authentication in support of shared dialin between organizations. This will likely have other implications and should have significant support from security area folks to be successful. Privacy-Enhanced Electronic Mail Working Group (PEM) The meeting covered implementation status reports, discussion of potential electronic notary services, PEM-MIME integration, certificate servers, and triple-DES. Only MIT and TIS implementation efforts were represented, but other implementations are proceeding in various countries. Dave Solo provided a presentation on various ``notary-style'' validation services for non-repudiation (see slides following the PEM minutes): simple time stamping, enhanced non-repudiation, document registration, archival signature validation, assurance issues, validation of other attributes. Two MIME-PEM designs now exist: o MIME-PEM ``lite'' (Jeff Schiller) o MIME-PEM ``full-bodied'' (Steve Crocker) These two proposals have different consequences and reflect some divergence in goals within the PEM and mail communities. Christian Huitema (INRIA) proposed a certificate server proposal for PEM to facilitate retrieval of certificates and CRLs with locally managed, simple databases. The index for search is the user's mailbox name. This calls for operators of the hosts that provide the user's mailbox to provide this responder facility. However, mail services such as CompuServ and MCIMail are unlikely to provide this service. A new record type may need to be created to allow indirection to other than the user's actual mailbox provider. Also, this proposal is based on TCP, but not all prospective PEM users are reachable by TCP, e.g., users of non-IP nets or firewall. There was a suggestion to add this facility to FINGER instead, to minimize firewall problems. It was proposed that email-based access should be baseline, with real-time access an optional additional service. Triple-DES was discussed briefly. At issue is the best method of using triple-DES in CBC mode. Burt Kaliski had circulated a summary of his findings, but he was not present for discussion. This remains an open topic. TELNET Working Group (TELNET) - Applications Area There is a draft specification combining both authentication and encryption security services. Implementations of the specification will be present for the next IETF. In addition, the draft document specifying the use of Kerberos Version 5 as a TELNET authentication option has expired. It will be resurrected. Router Requirements Working Group (RREQ) - Internet Area Due to lack of progress on the documents this work item was officially closed as a Security Area concern. If the working group is reconstituted to continue work then the security area will re-open this work item. In the time since the Houston IETF, this document has received renewed attention within the IESG and is now under the control of the Internet area. Domain Name System Working Group (DNS) - Service Applications Area The DNS Security sub-group of the DNS working group met to identify the threats, security services, and requirements of interest to the DNS. The requirements will be distributed to the mailing list for discussion until November 30, 1993. After that time, strawman proposals may be distributed until January 31, 1993. The group will evaluate all proposals with the goal of creating one proposal at the next IETF. It was decided to create a DNS security working group. In parallel with the activities above a charter will be drafted for review and submission to the IESG. Export Control Issues There was some consensus that there exists rumors that at least some of the rules regarding export may change soon. This work item exists to track this activity. (In the time since the Houston IETF meeting, no changes in United States policy have been announced.) IP: The Next Generation An IPng Directorate has been formed to track and evaluate the IPng proposals. Steve Bellovin is a member of the directorate representing the security area. Mobile IP Security There is a draft document describing what is identified as a weak security mechanism and how it can be used until IP security is available to provide strong security. Phil Karn will distribute this description to SAAG for review and comment. Random Number Generation Issues A revised Internet-Draft was distributed for comment. It has been published as an Informational RFC. Routing Security Plan This work item was re-assigned to Sandy Murphy at the Houston IETF. She will prepare a draft document summarizing the authentication and integrity issues in routing for the next IETF.