Editor's note: These minutes have not been edited. Date: Fri, 15 Dec 1995 15:15:32 -0800 From: Ran Atkinson Subject: IPsec WG Dallas minutes Minutes for IP Security Working Group 34th IETF, Dallas, TX, December 1995. These minutes are largely based on the notes taken by Richard Graveman during the meetings. The WG chairs thank him for his assistance in taking good notes during the meeting. Co-chair Paul Lambert was the floor moderator for most of this session. He was assisted by Randall Atkinson . Paul noted that both of the co-chairs recently changed employers and so have new email addresses. IP Security WG mailing list is likely to be rehomed early in 1996. If it moves, the change will be announced on the main ietf mailing list. The current (as of December 1995) mailing list addresses are: Postings: ipsec@ans.net Admin: ipsec-request@ans.net IP Security (IPSEC) Session 1, December 4th, 1995: -------------------------------------------------- RFC 1825 through RFC-1829 define the IP Encapsulating Security Payload (ESP) and the IP Authentication Header (AH). These were issued as Proposed Standard RFCs this past August. The discussions during the first IPsec meeting were focused on these specifications. LIAISONS: Ran noted that options in IPv6 are handled differently from IPv4. A bag of Hop-By-Hop options may follow the base IPv6 header. After these may come Destination Options and then the upper layer protocol (e.g. ICMP, TCP, or UDP). Destination Options are only handled by specifically listed destination systems for the IPv6 packet, while Hop-By-Hop options are handled by each intermediate system and end system (host or router). It might be useful to consider specifying AH for IPv6 as either a Hop-By-Hop Option or Destination Option rather than as a separate header. One advantage is that if AH were specified in this new way, the semantics of AH processing might be more clear for IPv6 implementations and two different semantics could be supported. Another possible advantage is to force AH to be parsed first at the destination(s), even though would not be handled at the routers. This is expected to be discussed more during the IPng WG meetings later this week. AH/ESP IMPLEMENTATION STATUS: Ran posed the following questions for all implementers: Whose implementation ? Implemented in what (host router, etc) ? Is it commercial or freely available? Which transforms were implemented ? It is known to interoperate with ? Which key distribution techniques are implemented ? Ran: The freely distributable NRL implementation covers IPv4 and IPv6 for hosts and routers, is based on 4.4-Lite BSD, Implements Keyed MD5 and DES-CBC, works with Karn and Morningstar, and has manual key management. A particular feature is that this implementation includes a Key Management Socket (PF_KEY) that permits key management daemons to be implemented outside the kernel in a portable manner. It is likely that NRL will document PF_KEY in an Informational RFC during the next few months. Additional transforms are easy to add to this implementation. Configured secure tunnels, dynamic tunnel-mode encryption, and transport-mode encryption are all supported using extensions to the widely used BSD network Sockets API. Applications that support use of IPsec via command-line options are also included in the distribution. See Dan McDonald or Bao Phan for more information. This implementation is freely available (modulo US Export Controls) and is reportedly online at ftp://ftp.c2.org MIT is expected to be the official archive site for the NRL software, but is still working on getting the software online. Enhancements to the NRL software are underway and will also become freely distributable. A paper on the details of this implementation will be presented at the January 1995 USENIX Conference. John Ioannidis ("JI") : This implementation was implemented in Greece, runs on BSDI, and will be freely available. It implements keyed MD5 and DES CBC, uses manual key distribution or Photuris (also implemented outside US) key distribution, and handles multiple transformations in any order with built in tunneling. Contact JI at for more information. Phil Karn: KA9Q implementation for hosts and routers based on MS-DOS, does encapsulation separately, will be distributable, uses keyed MD5, DES, and 3DES (IDEA perhaps next). It talks to at least Morningstar and NRL, and has manual key management. Photuris is planned for the future. Contact Phil Karn for more information. Mark Linehan: IBM's Pau-Chen Cheng has an implementation that runs on AIX, will be in a commercial firewall product. Mark indicated that they will have an exportable version, and uses manual key distribution. Pau-Chen has a copy of the implementation at the IETF so that interoperability testing can occur this week. Contact Pau-Chen for more information. Steve Bellovin: Two implementations were done last summer by David Wagner (UC Berkeley) while he was at AT&T Bell Labs. The first implementation runs on BSDI and uses keyed MD5 and DES. This AH is known to not interoperate with other implementations. The second implementation runs on MSDOS, uses keyed MD5 for AH, looks like a packet driver, so it can work with many boards and IP stacks. This has been tested with ftp Software and a paper on this implementation will be presented at ISOC in February. Contact Steve Bellovin for more information. Hilarie Orman: This implementation was done in the "x-kernel" research operating system at the University of Arizona. It is a user process in MACH, implements AH with keyed MD5, and implements ESP with DES CBC and 3DES. It has ping and ftp clients. Tools for manual key distribution exist. A Photuris implementation also exists. Will be freely distributable with the x-kernel software. Contact Hilarie Orman for more information. Ashar Aziz: Sun has implementations of ESP and AH with SKIP for SunOS 4.1.3 (kernel driver source), and Solaris 2.x (binaries only). Contact Ashar Aziz at for more information. Swiss Federal Institute of Technology: Runs on Solaris 2.x, IRIS, and NetBSD, freely distributable, implements AH and ESP with a fixed SPI (i.e. only works with SKIP key distribution). Key distribution is manual or with SKIP. Rob Glenn: NIST and NSA have an implementation of ESP and AH with MD5 and DES-CBC. It runs on BSDI, SunOS 4.1.x, FreeBSD, and NetBSD. They brought a FreeBSD implementation for interoperability testing and are working to make the implementation freely distributable within the US. Their implementation can use ISAKMP and was designed to support multiple security policies. Contact Rob Glenn for more information. Other: Two other implementations were mentioned without much detail. Jeff Kramer of Raptor has implemented some of IPsec. Antonio Fernandez of Bellcore has an AH implementation. Interoperability testing will occur in a hotel meeting room on Tuesday afternoon, thanks to Tim Matthews who arranged for the room. OPEN ISSUES: Where do current RFCs need clarification? The current RFCs will be cleaned up and reissued as Internet Drafts before the next IETF. Then everyone should send comments (preferably with replacement text) on confusing portions of the current specs so that the specifications can be cleared up prior to moving to Draft Standard RFC. We already meet the interoperability requirements to move to Draft Standard. Paul Lambert solicited implementor comments on AH/ESP RFCs and also on the DES, MD5, 3DES, and SHA tranforms RFCs: Bellovin and others asked which fields in the IPv4 header should be zeroed. There was consensus that this is the biggest problem with AH/ESP. Ran responded that the next version of the AH spec will specifically enumerate which IPv4 options and header fields are included in AH calculations and which are zeroed. A note to the IPsec WG mailing list late last August enumerated these in more detail than was present in the RFCs. The options important to include in the Authentication Data calculation are IPSO (RFC-1108)and CIPSO (no public specification exists). JI suggested adding sequence numbers to AH. It is in the Photuris extensions draft and would use the 16 bits of reserved AH header. Bob Moskowitz brought up concerns about interactions with firewalls. Perry Metzger brought up need for ways to use (fast) stream ciphers (synchronization problem). Bill Simpson asked for comments on the transform RFCs. The main comment was that many implementers have been confused on how to perform the MD5 padding. Hilarie Orman suggested including example C source code in an informational Appendix to the MD5 transform draft in order to make this more clear. NEW TRANSFORMS: Hugo from IBM discussed an alternate approach to Keyed MD5. RFC 1828 specifies: MD5(K pad x K). New nested mode: MD5(K padsub2 MD5(K padsub1 x)) |K| = 16 bytes padsub1 = 0x36 repeated 48 times padsub2 = 0x5C repeated 48 times Hugo's Comparison: - is still MD5 based (available, unrestricted, good performance) - is replaceable (SHA, MD6, ...) - no performance degradation - short keys, simple setup - MD5 unchanged - better security: * improved analysis * weaker assumptions about hash function * tighter security: MAC as secure as underlying hash function * double key effect He asserted that to break the new MD5 transform, either the output of the MD5 compression is predictable or MD5 collisions can be found even when the IV is secret and random. Both of these are believed to be untrue for MD5. The underlying construction considers MD5 with the IV set to K. Only one K is needed but the pads have to be different. Also, for added efficiency, implementations can compute the first block once and use each time with a given key. Much discussion followed. Perry Metzger, Bill Simpson, Hilarie Orman, JI, Steve Bellovin, Ted Ts'o, Bob Moskowitz, Phil Karn, and Jeff Schiller had comments on this. Simpson suggested using Hugo's approach with SHA and not MD5. Hilarie asked where Hugo's analysis could be obtained and noted the need for outside cryptographic and mathematical review of Hugo's proposal. WG Consensus seemed to be: Put this new transform out as a Proposed Standard (Elective) in its own RFC with a new transform identifier. Advertise that either 1828 or this new transform might become the required future transform when we move to Draft Standard. In order to move the new transform to Draft Standard, at least 2 independent interoperable implementations must exist and be demonstrated interoperating. OTHER TRANSFORMS: Paul Lambert noted that there might be other transforms (e.g. DES-CBC integrated with MD5 for use with ESP) needed. He solicited volunteers to write up additional drafts. Only Bill Simpson and Perry Metzger volunteered. Other volunteers are still solicited by the WG chairs. Volunteers should write up their proposed transforms and put them out as Internet Drafts (filenames of the form draft-LASTNAME-TRANSFORM_NAME-*.txt should be used) and mention the published I-Ds on the WG list. IP Security WG, Session 2, 6 December 1995: ------------------------------------------- This session was mostly focused on key management and related issues. Paul Lambert showed the matrix of AH and ESP interoperability testing. The grid was about half filled in. Ran observed that not all combinations of implementations had been tested, so a blank space was not necessarily indicative of non-interoperability. A number of implementation bugs were found and fixed on Tuesday during the information interoperability testing session. Two SKIP implementations worked together. Two Photuris implementations worked together. The group was pleasantly surprised at the rapid progress towards interoperability and the unexpectedly large number of independent implementations. LIAISONS: ANSI: John Kennedy discussed ANSI X9F. There are two drafts: X9.52 for Triple-DES (3DES) is near working draft status. Contact Bill Latin +1 (408) 735-6679 or via email at for more information on X9.F2. X9.42 is on Diffie-Hellman (DH). Contact John Kennedy at +1 (408) 735-5885 or via email to kennedy@cylink.com for more information. Also ANSI X9.55 is tracking the X.509 Public Key certificate standards work; see Russ Housley or Warwick Ford for more information. IEEE Microprocessor standards: This group covers RSA, DH, and related techniques. Burt Kaliski is the Chair. See ftp://ftp.rsa.com for more information. Elliptic curve (EC) implementation of discrete log systems is going to ballot within IEEE. The patent situation is different for EC than DH. Other sections on RSA, DH, and random number generation. The next meeting of this IEEE group is the two days before ISOC Security Symposium that will be held during February in San Diego. The usual comments about the need for no-cost on-line availability of these non-IETF specifications followed. PATENT ISSUES: Paul Lambert noted that many of the technologies discussed by the IPsec WG might be affected by patent claims. He then tried to summarise all known patent claims that might be issues. Ashar noted that the Sun patents relating to SKIP are available for use at no cost. Patents claimed by NeXT are reportedly under negotiation. Hugo noted that IBM issued an RFC on use of one of their patents. UUNET has a US patent claim on all network encryption. Novell has a claim on the use of Message Authentication Codes such as Keyed MD5. Motorola has patent claims on certain compression techniques. Paul solicited information on non-US patents, but no one had any information on this. It was suggested that any other known patent claims be mentioned on the IPsec mailing list. For Cylink: see http://www.cylink.com or telephone Bob Fougner at +1 (408) 735-5893. For RSA, see http://www.rsa.com or telephone Paul Livesay at +1 (415) 595-8782. For UUNET, contact Rick Adams ELLIPTICAL CURVE PRESENTATION: Hilarie Orman presented an argument for using Elliptical Curves instead of Modular Exponentiation with Public-key technology. She showed a graph illustrating that to get more key bits, DH compute time increases rapidly even using Karatsuba multiplication and Montgomery reduction. For DH modulus M, |M| = 512-2048 bits and exponent E, |E| = 128-256 bits, compute time is |E| |M|^1.6. Strength depends on: minimum(E/2, 2.5M^(1/3), log(M)^((2/3)-15)). Using |E| = 128, |M| = 512 really only yields 53 bits of equivalent DES key strength. This estimate used an interpolation into an asymptotic bound for the number field sieve based on the factoring of a 119 digit number with that method. ECs give equivalent strength with 155 bits over a field of characteristic 2. More information on this subject is available at http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html. Hugo questioned some of the conclusions that Hilarie drew. The WG was very interested in Hilarie's presentation but no consensus either way was obvious. The matter remains open for further study and discussion. ALTERNATIVE ENCRYPTION ALGORITHM: John Kennedy presented Jim Massey's "Safer SK" algorithm. This is a 64 bit block cipher with 40, 64, or 128 bit keys. It is freely available and robust against differential and linear cryptanalysis. He suggested that this might be of interest. It was suggested that he document an ESP transform for this as an Internet Draft so that the WG could discuss this proposal in more concrete terms. It was also suggested that an Informational RFC documenting the cryptographic algorithm would be helpful. KEY MANAGMENT: Paul then turned discussion towards the currently available Internet Drafts on Key Management technology. There are 3 documents online at present, namely Photuris, SKIP, and ISAKMP. Photuris: Phil Karn presented the changes to Photuris. Interchangeable parts of the protocol may lead to weaknesses (exchange, key generation, signature). Two implementations exist today that interoperate: JI (University of Crete) and HO (University of Arizona). Also work is underway or contemplated at NRL (on top of PF_KEY), and by Simon Spero and Phil Karn. Phil expects a "bottom up" deployment from AH and ESP to cases where a public key already exists, say in a password file, and access control is being enforced. Two questions were posed: How to support multiple ESP transforms ? How to support user-to-user keying ? Phil Karn then solicited issues from the WG and came up with the following list: 1. Are options for the station-to-station (STS) phase necessary ? 2. What is the public key certificate infrastructure ? 3. Security association attribute negotiation is needed. 4. Document is too long and hard to comprehend. 5. Session key from shared secret: use of dependent keys. 6. Should encryption for privacy in STS really be mandatory ? 7. Is there potential for convergence with SKIP ? SKIP: Ashar Aziz presented SKIP to the Working Group. Since Danvers there have been several major changes such that the current draft is not compatible with older SKIP implementations. Specifically, - The SKIP header now only performs key management and ESP/AH are used for IP authentication or encryption. The new structure is: [IP header][SKIP header][AH or ESP][upper-layer protocol] - A public-key Certificate Discovery Protocol based on UDP was developed in order to obtain long-term keys. This allows multiple certificate types (PGP, X.509, etc.) and can be run bilaterally or with a central server. One effect of this change is that SKIP now has some state. Ran Atkinson asked to move this protocol into a separate draft from SKIP so that it could be used more generally rather than only for SKIP. Ashar agreed to make this change. Phil Zimmermann stated that this protocol will work with a new release of PGP expected in January 1996. - A "SKIP Algorithm Discovery Protocol" based on ICMP has been added. This message is authenticated but is sent in the clear. This addition also adds state into SKIP. - Naming is now disassociated from source and destination IP addressees: This helps support mobile hosts with dynamic IP addresses better. - A specification bug relating to IP multicasting was fixed. Two "SKIP with ESP and DES-CBC and certificate discovery" implementations interoperate. Raised hands from the audience indicate that other implementations of this are being considered. ISAKMP: Mark Schertler presented the ISAKMP specification. Their goal is to have a single key management protocol that is usable by ESP/AH and also other protocols (e.g. SSL, PCT, RIP-II, 802.10 SDE, TLS, OSPF). They seek independence from security policy, mechanism, and algorithm. All approaches that have been proposed in the WG allow protocol as well as crypto attacks. The focus of his work has been on resolving the protocol attacks. The main changes are: 1. User Negotiation protected by server established SA, 2. Situation (usage policy), 3. Authentication only mode, 4. Version number. They brought a prototype demonstration on DTOS microkernel that was shown afterwards in the hallway. This implementation could be moved to BSD with little difficulty. They have the TIS version of DNS Security (DNSsec) running on SunOS 4.1.3, and they can extract certificates from Fortezza tokens and may use PGP certificates in the future. The implementation is not copyrighted and available to US citizens or government agencies. They are willing do interoperability testing with independent implementations from outside the US. Mark then commented on the other key management protocols: SKIP works best with connectionless protocols and does not support security association management. Photuris is ESP and AH specific and not compatible with security tokens (this was challenged by Simpson and was deferred for further discussion). WORKING GROUP SUMMARY: Paul observed that SKIP is now in WG last call for Proposed Standard (Elective). Jeff Schiller asked whether SKIP meets the WG charter? What about perfect forward secrecy? At Ran's request, Jeff then summarised the property of Perfect Forward Secrecy and why it is important. Jeff then described the IETF standards process. Hugo asked whether perfect forward secrecy is still a consensus goal for a mandatory standard? Ashar responded by explaining the limited forward secrecy possible with SKIP. Karn stated that Perfect Forward Secrecy should be at least available. Bob Moskowitz stated that Perfect Forward Secrecy is sometimes necessary in a business environment. Perry Metzger mentioned need to support multiple mechanisms. WG CONSENSUS: There was very clear working group consensus that Perfect Forward Secrecy remains a requirement for any specification moving forward as a mandatory-to-implement IETF standard. SKIP does not claim to provide this property, while Photuris claims to provide it. ISAKMP can support a session-key exchange that provides this property but does not currently specify any session-key exchange algorithm.