CURRENT_MEETING_REPORT_ Reported by Paul Lambert/Motorola Minutes of the Internet Protocol Security Protocol Working Group (IPSEC) The IP Security (IPSEC) Working Group met twice during the IETF in Toronto. On Wednesday the IPSEC Working Group met and discussed the IP Security Protocol (IPSP). On Thursday the working group discussed IPSEC key management and possible algorithms and embodiments of the Internet Key Management Protocol (IKMP). Wednesday - IPSP A brief summary of the working group status, charter, goals, and related work was presented. The IPSEC Working Group will develop a security protocol in the network layer to provide cryptographic security services to protect client protocols of IP (IPv4 and IPv6). The protection shall support combinations of authentication, integrity, access control, and confidentiality services. The IP Security Protocol (IPSP) shall be independent of the cryptographic algorithm and support host-to-host security, and subnet-to-subnet and host-to-subnet topologies. Many implementations and specification of network exist. The swIPe protocol has recently been released as a freely available software. A brief summary of swIPe was provided by Perry Metzger. Paul Lambert gave a brief overview of the Secure Data Network System (SDNS) protocol SP3. Many implementations of SP3 or SP3-like devices exist, but none are freely available. Few of these implementations interoperate (a feature?). It was noted that SP3 cannot directly protect TCP without a selector of some sort. The SP3 SAID controlled formats inside the packets: permits IP sandwich or a non-IP sandwich. The SP3 features provided a little of everything. The problems with SP3 include a difficult to read specification, unnecessary fields in the clear header (very minor problem), and closely tied to ISO TP (makes support of TCP and other Internet protocol slightly harder). Rob Glenn, of NIST discussed NLSP and his recent enhanced proposals. He felt that NLSP was not a bad place to start, but was difficult to understand, overly complex, had an inefficient packet structure, was flexible and extensible, but too much so. NLSP was rejected by the IPSEC Working Group. Rob has documented two proposals that have evolved from his work with NLSP. He has an implementation of I-NLSP done in the BSD 4.4. kernel and has offered to release the code. The working group has defined a baseline approach and format for IPSP based on the lessons learned from existing implementations. The approach is to define a simple cryptographic encapsulation protocol that supports algorithm independence through the use of a Security Association Identifier (SAID). The baseline consists of a single field in the Rclear headerS - the SAID. The SAID is pre-established and is used to determine the algorithm, key, and protocol formats for the Rsecurity transformationS. The only information that must be carried (besides the protected data) in the protected portion of the PDU is a ``next protocol'' field. At least two security transformations will be defined in the base specification. Currently the group seems to favor including DES-CBC-MD5 (for confidentiality and integrity) and Keyed-MD5 (for integrity and authentication only). Additional transformations may include facilities for sequence integrity (without recovery), and additional algorithms (IDEA, triple DES, etc.). A version number was proposed for inclusion in the first three or four bits of the clear header of the protocol (or as the first bits of the SAID). Steve Bellovin described authentication in IPng. Authentication is required, encryption will not be used everywhere. Packet filters may need to filter data encapsulated within an authentication header. SIPP defined a separate payload type for the authentication-only header. Summary of IPSP Issues Protocol numbers need to be assigned for IPSP. A proposal to use one of the SIPP/IPng numbers was made and will be investigated. The relationship of IPSP to the SIPP authentication only header needs additional investigation. More documentation of IPSP is required (Perry Metzger has volunteered to edit). The use of SAIDs with multicast needs to be clarified. Key management attributes need to be defined for IPSP for use in the negotiation by key management. Thursday - IKMP IPSEC key management is an application layer protocol that will be developed independently of IPSP. It is coupled loosely to IPSP via the SAID. The Internet Key Management Protocol (IKMP) is expected to handle negotiation of cryptographic algorithms, protocol format and protocol options. The functional requirements for IPSP include SAID assignment, key generation/distribution, attribute negating, terminate/delete association, SAID maintenance, peer discovery and authentication, recovery, multiparty associations, etc. Multiparty associations are important for multicast. Phil Karn has been building an experimental protocol. He has introduced a goal of eliminating ReasyS denial of service attacks. His RphoturisS system currently uses Diffie-Hellman techniques. Other design goal is to hide as much identity information as possible in the protocol. Numerous key management specifications and implementations exist that could be leveraged to help create IKMP. These include SDNS KMP, SAMP, IEEE 802.10C, GULS (sense is that ISO specification is too ugly) PEM might provide certificates, or perhaps PGP. DNS security work may be a good source for certificates. SAEP is connected to NLSP but may have some good components. Kerberos was mentioned as a key management approach, but does not meet current requirements. John Linn gave a presentation on the relationship of GSS/CAT API to IPSEC. The CAT work is focusing on providing callable services to application protocols, which use RcredentialsS to produce security contexts. Applications should not care about what mechanism is used. IKMP could be one of these mechanisms. Implementations of variety of underlying mechanisms exist. Some of these existing mechanisms could also be used to establish keys for IPSP (like Kerberos). Ashar Aziz presented SKIP - simple key management for IP. Hugo Krawczyk presented a Secure Tunnel Establishment Protocol. Amir Herzberg presented ideas on key look-ahead for key management. Steve Bellovin discussed his personal key management requirements. He feels that excessive options are a bad thing---negotiation should be as simple as possible, as minimal as possible. Presenters are encouraged to publish PostScript versions of their viewgraphs to the IPSEC FTP archive. Jim Hughes has established an FTP archive for IPSEC at ftp.network.com:IETF/IPSEC. Summary of IKMP Issues How does the IPSEC IKMP relate to other IETF key management related activities? How are shared keys established (e.g., for multicast)? What name and certificate structures should the IKMP support? Need to work quickly to field workable solutions. An interim IPSEC meeting for key management was proposed. This meeting will occur before the next IETF plenary and the agenda and location will be posted to the IPSEC mailing list.