CURRENT_MEETING_REPORT_ Reported by Paul Lambert/Motorola Minutes of the Internet Protocol Security Protocol Working Group (IPSEC) The IPSEC Working Group met during the twenty-ninth IETF and discussed the IP Security Protocol (IPSP) and IP Key Management. Two separate meetings on these topics were originally scheduled, but a conflict with security topics presented during the Wednesday plenary forced the combining of the two sessions. IP Security Protocol Status and Discussion A brief summary of the working group status, charter, goals, and related work was presented. The working group has been slow in developing an Internet-Draft for the IP Security Protocol (IPSP). There are many specifications for RNetwork Layer SecurityS (SP3-N, SP3-A, SP3-I, SP3-D, SP3-C, NLSP, I-NLSP, swIPe, PIP and others), but there currently is no consensus approach represented in an Internet-Draft. There are also many implementations of various flavors of IP layer security (ANS, AT&T, DEC, Hughes, Morningstar, Motorola, Semaphore, UUNET, Qualcom and others). So far, none of these implementations interoperate. A presentation was given describing a proposal being developed by Jim Zmuda and Paul Lambert. The proposal represented work developed from the February 1995 ISOC Symposium on Network and Distributed Systems Security (SNDSS). A generic protocol format supported any cryptographic encapsulation technique. A specific example (also suggested as a default) used DES for the encryption algorithm and MD5 as an integrity check value algorithm. Donald E. Eastlake gave a verbal description of the draft specification that he had posted to the mailing list earlier in the morning (PIPS: Practical IP Security). This document describes protocol formats and processing for a IP layer security mechanism that combines the encapsulation mechanism and key management. The use of sequence numbers in the protocol to provide replay protection was discussed. Large sequence numbers could provide good protection from replay using a sliding window approach for validation. No reliability (re-transmission) would be provided by this security mechanism. A suggestion to the use of compression techniques with IPSP was made during the course of the discussions. Network layer encryption will beak existing techniques that compress the TCP and IP protocol information. Compression could be provided as part of the IPSP processing. On transmission, the data would have to be compressed prior to encryption. Numerous individuals in the meeting indicated that they were developing or planning to develop implementations of IPSP. An interoperability demonstration will be scheduled for the July 1994 IETF meeting. The group in the room seemed to converge on the use of DES for encryption, MD5 for confidentiality, and manual key management for the initial interoperability tests. Key Management The discussion of IPSEC key management was started with a brief review of the working groups key management charter and goals. The group is chartered to develop an application layer protocol and cryptographic techniques to provide peer-entity authentication and key management for the IPSP. The peer-to-peer authentication exchange will support public key cryptographic techniques and negotiate options for IPSP. A rough draft of a protocol for IP Key Management (IPKM) was posted by Dave Solo. Work is progressing in other working groups on the definition of certificate structures, certification hierarchies, and certificate distribution. The IPSEC-defined IP Key Management (IPKM) should use as much of the existing work as possible for support of the public key based mechanisms. Discussions on the relationship of IPSP to the other working groups examined the overlap of these mechanisms. Several members of the group expressed strong opinions that the IPSEC Working Group should focus on the authentication exchange and directly use work from other groups for the distribution of certificates. In particular, the DNS security techniques will provide certificates that could be used by IPKM in an authentication exchange. It was proposed that at a minimum the IPKM should provide authentication for IPSP based on network addresses. DNS names, PGP identities, and PEM identities were also proposed as possible approaches for peer-entity authentication, but no consensus on these approaches was evident. The IPSP authentication exchange, being separate from IPSP, should be usable by other protocols that may need an authentication exchange. In this context, the group discussed how the IPKM requirements relate to GSS-API and Kerberos. The IPKM authentication exchange should be compatible with the GSS-API and could serve as one of the GSS-API methods. Other GSS-API mechanisms, like Kerberos, could also be used to distribute keying material for the establishment of a security association for IPSP. John Linn and Paul Lambert volunteered to write a short Internet-Draft on IPSEC and the GSS-API for the next meeting. Phil Karn presented a proposal for an authentication exchange based on the Diffie-Hellman public key algorithm. Public key information is first exchanged that allows the creation of a private key held only by the two peer systems. Using these keys to encrypt subsequent PDUs, additional protocol exchanges authenticate the identity of the peer systems. This approach allows for the creation of a security association without revealing the identities of the two peer-systems. This exchange was nearly identical to the Diffie-Hellman exchange documented in ISO 11577 (Network Layer Security Protocol - NLSP). Phil suggested that the certificate formats and distribution could be provided by PGP (Pretty Good Privacy, a specification for secure electronic mail). Phil introduced a concern that the processing time required to calculate the public key algorithms would increase the susceptibility of a system to denial of service attacks. He suggested that protocol exchanges could be introduced to minimize the spoofing of network addresses in the exchange. Charlie Perkins (IBM) presented a key distribution and authentication system called Net/SP/KryptoKnight. This work is available as a product on AIX, OS/2 and GSS-API. It is exportable, Kerberos-like, and uses symmetric key distribution and authentication. Attendees Garrett Alexander gda@tycho.ncsc.mil Mark Allyn allyn@netcom.com Ward Bathrick ward@mls1.hac.com Kym Blair kdblair@dockmaster.ncsc.mil Stephen Crocker crocker@tis.com Cheri Dowell cdowell@atlas.arc.nasa.gov Donald Eastlake dee@lkg.dec.com Robert Enger enger@seka.reston.ans.net Louis Fernandez lff@sequent.com Barbara Fraser byf@cert.org Chris Gorsuch chrisg@lobby.ti.com Richard Graveman rfg@ctt.bellcore.com Marc Hasson marc@mentat.com Song Kwan Ho khsong@hen.nca.go.kr Jim Hughes hughes@network.com Charlie Kaufman kaufman@zk3.dec.com Hiroshi Kawazoe kawazoe@trl.ibm.co.jp Stephen Kent kent@bbn.com Paul Lambert paul_lambert@email.mot.com John Larson jlarson@parc.xerox.com Ben Levy seven@ftp.com John Linn linn@security.ov.com Steven Lunt lunt@bellcore.com Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Masataka Ohta mohta@cc.titech.ac.jp Peter Phillips pphillip@cs.ubc.ca Michael Ressler mpr@ctt.bellcore.com Oscar Strohacker stroh@vnet.ibm.com Dale Walters walters@osi3.ncsl.nist.gov Suguru Yamaguchi yamaguti@wide.ad.jp Dan Zerkle zerkle@cs.ucdavis.edu