CURRENT_MEETING_REPORT_ Reported by Paul Lambert/Motorola Minutes of the Internet Protocol Security Protocol Working Group (IPSEC) Many thanks to Tom Benkart who served as recording secretary for these meetings. The IPSEC Working Group met twice during the Twenty-Eighth IETF. On Tuesday, November 2 the IPSEC working group met and discussed the IP Security Protocol (IPSP). On Wednesday, November 3 the working group held a demonstration of two IPSP implementations and discussed the key management requirements of IPSEC. Working Group Status Paul Lambert began the meeting with a review of the charter and a working group status report. o The working group is behind schedule. o Only I-NLSP has been submitted as an Internet-Draft. o It is important to track the IPng candidates. Since I-NLSP is the only Internet-Draft so far, it may be used as the template for a document from the entire group. That does not mean that its concepts would be adopted, just that it provides the working group with a starting point. Richard Thomas stated that the NLSP specification may be available electronically soon. It is on the list of documents to be made available from ISO. IPSP Requirements Review Agreement must be reached on the requirements before the contending proposals can be evaluated. Requirements were discussed in Amsterdam, but the decisions were not considered final due to the small number of participants. Since the minutes from that meeting were not published, the working group as a whole did not have a chance to comment. The following comments reflect points from the Amsterdam and Houston meetings. o Encapsulation versus IP option - encapsulation was selected. o Limited coupling between key management and IPSP - agreed; the only coupling will be the SAID. o Use of TLV encoded fields - rejected (speed favored over flexibility). o SAID implies the label to minimize the information carried per packet (key management exchanges are far less frequent). The label can also be carried as part of the protected data (i.e. normal IPSO in protected IP header). o Sequence numbering is an open issue. o A flags field in the clear header is an open issue. Donald Eastlake will post something to the mailing list stating his view of its usage. o A protocol field in the IPSP header is probably needed. It could be eliminated by having the SAID imply that information also, but there is controversy about using the SAID for this purpose. o An ICV will be included in IPSP. o Peek-through (to see the upper level protocol/ports) will not be supported. Mechanisms such as mapping this information into QOS can be used to meet the needs of firewalls (although firewalls themselves were not universally liked in the working group). o Multicast was listed as an issue but not discussed due to lack of time. o No decision was reached about fragmentation and reassembly support in IPSP. Fragmentation was the major item addressed and remains an open issue. Protocols such as NFS send maximum-sized UDP datagrams, and the encapsulation done by IPSP in ISs frequently results in additional fragmentation. MTU Discovery can be a solution (provided the routers account for the IPSP encapsulation in their ICMP messages), but MTU Discovery is not commonly used today. NFS 3 runs over TCP, so this might not be so large an issue when that version is available. Reassembly is not required in IPSP as long as layering is maintained. For example, in the case of IPSP between two ISs, reassembly is handled by the normal IP processing since the added IP header specifies the remote IS as the IP destination. Jim Zmuda and Bill Simpson volunteered to write a requirements document based on the discussions. Experimental IPSP Implementation Review o I-NLSP - Rob Glenn - NLSP is a starting point for reaching consensus within the working group. - I-NLSP is NLSP-CL along with any enhancements the working group specifies. - Including a content length field in the protected data is useful with random padding. - A sample implementation is done (CLNP only), but it is not optimized. o swIPe - Phil Karn - Authentication is faster than decryption, so the authentication field is in the unprotected header and is checked first. - Minimal header size is emphasized over good alignment of fields since Phil's application involves low-bandwidth lines. - With a single system sometimes being an IS and sometimes being an ES, potential problems arise depending on where in the IP logic IPSP is placed. - The working group probably will not be able to agree on a single IPSEC PDU format because of the wide range of bandwidths being discussed. - Sequence numbers are used to guarantee different packet contents for seeding the CBC (essentially acting as an IV). Future uses for the field are still up in the air. o KeyRing - Rob Hagens - Target application is gateway-gateway (IS-IS). - Small window of valid sequence numbers is allowed to prevent replay. - Fragmentation is not an issue since it always does IP over IP with a remote IS as the outer IP destination. o TANDU/Cryptonette - Charlie Kaufman - Target is cheap universal encryption running at LAN speeds. - Hardware solution in a chip to be added to interface cards. - No performance penalties (including extra copies). - Stateless encryption by including the algorithm and session key in the clear header. The session header is encrypted under the recipient's master key. The session key field must be large (8 bytes for DES). - Fragmentation/reassembly has been implemented in this layer for performance reasons. - The ICV is at the end of the packet to minimize processing latency. - Any fragmentation of the datagram by routers in between the encryption systems causes a large performance penalty because of the stateless decryption. o LAN Guardian - Mike O'Dell Uses UDP as part of the encapsulation mechanism because of fragmentation and reassembly issues. In the future, it may tunnel over TCP to facilitate CBC. Several people in the group expressed concerns about this because of possible TCP attacks. Also, adding TCP would impact real-time protocols. o SP3 - Paul Lambert In the SP3 specification the SP3-D and SP3-A are the modes of most interest to the working group. SP3-D is a version of dual-IP encapsulation. SP3-A provides a dual address space without the duplication of the IP header. The question of supporting multiple PDU formats as part of the IPSP specification is an open issue. Arguments in favor are that different media types will need different formats to be efficient, and that ES-ES IPSP could do TCP-UDP over IPSP instead of IP over IP encapsulation. Arguments opposed are that the added complexity will make IPSP more difficult to specify and implement. One possible approach is to specify a negotiation mechanism with defaults (like PPP). IPSP Implementation Demonstrations 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. Key Management What is key management and what is the groups charter for key management? o A protocol and cryptographic techniques. o Application layer protocol for IPSP. o Independent of IPSP. o Initially supporting public key techniques (not patent issues!). o Later adding Key Distribution Center (e.g., Kerberos) and/or manual. Existing work we might be able to take advantage of: o There is nothing that directly applies, but many pieces exist. o SNDS KMP - Missing some things like algorithms and algorithm negotiation. o IEEE 802.10C - Available in draft form, still very rough and is based on GULS. o ISO GULS - Specifies generic envelopes, very complex, no specific algorithms or option negotiation. o PEM - Not real-time, but does address certificates and public keys. o X.509 - IPSEC will likely use X.509 certificate formats. o X9.17 - Private keys, now working on public keys. o SAMP - 2nd generation SDNS KMP, may be posted to net soon. o SAEP - Embedded in NLSP, network layer protocol. o Kerberos - Private keys centrally managed. o CATS-GSSAPI - IPSP KMP might be able to use their interface to pass information to IPSP; also an outstanding question of whether IPSP will meet their needs from a user perspective. Key Management Liaisons: o IEEE 802.10C - Peter Yee o Kerberos - John Linn o Others still required for ISO, and ANSI Key Management Requirements This meeting was the first attempt to list the requirements for a KMP. The requirements fall into two categories - Peer-to-Peer Exchanges and Security Management. Peer-to-Peer Exchanges o Authentication Mechanism/Algorithm Negotiation - we will support multiple algorithms. o Peer-Entity Authentication - often built into the key exchange. o Key Establishment - obtain or create a key for use by IPSP. o Security Association Negotiation - we need to agree on a definition of a Security Association (SA). It's more than just keys, especially since we are trading off simplicity in IPSP for added context implied by the SA. The SA probably includes the algorithm, key, label, and services. o Termination of SA - what is a "session", what is its lifetime? IPSEC is mixing a connectionless IPSP with a connection-oriented SA. What are the recovery mechanisms (e.g., do "aborts" have to be authenticated)? Security Management o Certificate Distribution - Peer-to-Peer or via a third party. o CRL List - Possibly support through SNMP. o Centralized Key Distribution - Used for shared keys/multicast. We may defer work on this item until later. o Access Control Attributes. Issues o Device name and address implications for directories and certificates. o Authorization List/Delegation - what hosts is an IPSP router permitted to act as a proxy for? Is this information dynamically discovered or statically configured? Dynamic is more flexible but potentially adds much more complexity. o How are IPSP access lists for routers distributed and maintained? o Can a SA change, or is a change accomplished by terminating an old SA and establishing a new one?? o Shared keys - used for multicast or (possibly) multiple IPSP routers serving a site. Existing hosts have to be able to take advantage of IPSP services in routers without any change to the host (i.e., IPSP is transparent to non-IPSP end systems). Dave Solo volunteered to write a requirements document for IPSEC Key Management. Concern was expressed about supporting public keys first in the IPSEC goals because of possible delays from patent issues (a lesson learned by PEM). Having a standard API for communicating keys from the KMP entity to IPSP would facilitate support for private/shared keys. Existing Key Management Implementation Presentations Rob Hagens gave a presentation on KeyMan product. Following are attributes of the product: o The routers have a pre-configured list of peer entities. o A Key Encryption Key is used in the current Beta release; a new version using public/private keys is in development. o Traffic key lifetimes are dynamically specified. o Different TEKs are used in each direction; setup can be done in two messages, but four are normally used. o All PDUs have the same format (48 bytes). o Public keys are currently locally stored (manual distribution). o TEK generation does not use Diffie-Hellman, so recorded traffic could be decrypted if the private keys are ever learned. o If a router crashes, it establishes new SAs; the other routers discard the old SA when a new setup is requested. Jim Zmuda gave a presentation of key management in the NetLock product. It uses SAEP and a trusted Certification Authority on at least one of the systems. A Diffie-Hellman exchange is used to generate a secret for shared keys. The secret is also encrypted with the sender's private key for authentication. Attendees Garrett Alexander gda@tycho.ncsc.mil Randall Atkinson atkinson@itd.nrl.navy.mil Alireza Bahreman bahreman@bellcore.com Steven Bellovin smb@research.att.com Tom Benkart teb@acc.com Larry Blunk ljb@merit.edu Ken Carlberg Carlberg@cseic.saic.com Cheng Chen chen@accessworks.com Richard Colella colella@nist.gov Stephen Crocker crocker@tis.com Waychi Doo wcd@berlioz.nsc.com Robert Downs bdowns@combinet.com Donald Eastlake dee@skidrow.lkg.dec.com Antonio Fernandez afa@thumper.bellcore.com Richard Fox rfox@metricom.com Dan Frommer dan@isv.dec.com Vincent Gebes vgebes@sys.attjens.co.jp Jisoo Geiter geiter@mitre.org Robert Glenn glenn@osi.ncsl.nist.gov Mei-Jean Goh goh@mpr.ca Chris Gorsuch chrisg@lobby.ti.com Phillip Gross pgross@ans.net Robert Hagens hagens@ans.net Phil Karn karn@qualcomm.com Charlie Kaufman kaufman@zk3.dec.com Elizabeth Kaufman kaufman@biomded.med.yale.edu Stephen Kent kent@bbn.com Edwin King eek@atc.boeing.com Michael Kornegay mlk@bir.com David Kristol dmk@allegra.att.com Paul Lambert paul_lambert@email.mot.com John Linn linn@security.ov.com Brian Lloyd brian@lloyd.com Kanchei Loa loa@sps.mot.com Steven Lunt lunt@bellcore.com Gary Malkin gmalkin@xylogics.com Glenn McGregor ghm@lloyd.com Michael Michnikov mbmg@mitre.org Greg Minshall minshall@wc.novell.com Sandra Murphy murphy@tis.com Andrew Myles andrew@mpce.mg.edu.au Michael O'Dell mo@uunet.uu.net Steve Parker sparker@ossi.com Henning Schulzrinne hgs@research.att.com Vincent Shekher vin@sps.mot.com William Simpson Bill.Simpson@um.cc.umich.edu Frank Solensky solensky@ftp.com Dave Solo solo@bbn.com James Solomon solomon@comm.mot.com Michael St. Johns stjohns@arpa.mil Don Stephenson don.stephenson@sun.com Richard Thomas rjthomas@bnr.ca Susan Thomson set@bellcore.com Dean Throop throop@dg-rtp.dg.com Jerry Toporek jt@mentat.com Paul Traina pst@cisco.com Theodore Ts'o tytso@mit.edu Anthony Valle valle@huntsville.sparta.com Chuck Warlick chuck.warlick@pscni.nasa.gov David Woodgate David.Woodgate@its.csiro.au Peter Yee yee@atlas.arc.nasa.gov James Zmuda zmuda@mls.hac.com