Editor's note: These minutes have not been edited. IPSEC WG Meeting Notes, Montreal IETF, June 1996 The co-chairs would like to thank Steve Kent for contributing his personal notes on the meeting, which were used as the basis for these minutes. The co-chairs edited the notes somewhat, so any errors are their responsibility. SESSION 1, Tuesday: AH/ESP and existing IPsec documents Jim Hughes presented his Combined ESP transform with HMAC and anti-replay. Steve Kent suggested changing the proposal to rely on a negotiated anti-replay window size, to accept all packets within the window unless they are replays, and to not try to reduce the overhead by relying on a constructed IV. All three suggestions were adopted. Note that this protocol requires distinct simplex channel keys, derived from a master key for the SA. RSA reported on their S/WAN interoperability testing: TIS, NSA, Raptor, SCC, and others worked well together. The next test session will require Oakley/ISAKMP, and optionally SKIP, for key management, in support of AH and ESP. John Gilmore argued for widespread, near term deployment to protect against passive wiretapping. His goal is 5% of Internet traffic by the end of 1996. His personal agenda is to counter government (not just US Government) efforts for key-escrow initiatives. His proposal is to put crypto-walls in place (devices that don't even do packet filtering and don't rely on authenticated keys). His tactic is to leverage freely available software in order to build such crypto-walls, define new DNS records for unauthenticated key storage, avoid export controls by developing software outside of the US. A firewall vendor gave a talk on using IPSEC with firewalls, as a followup to mobile IP problem of getting mobile IP traffic out of a foreign domain. Asssume a model where presence of valid AH is required for firewall traversal, in either direction. The initially presented model looks at traversing a single firewall, nominally at the home agent permieter. The second model presented shows foreign and home firewalls. The talk points out the need for multiple, layered SAs, from MN-to-firewall-1, then maybe between firewalls, then from HA to firewall-2, and eventually one SA above these to carry forwarded traffic from HA to MN. Speaker notes the problems of being able to transmit the mobile IP messages, ICMP messages, and key management messages through firewalls as a precursor to establishing SAs in this complex environment. The bottom line is that one has to look carefully at the rules that firewalls employ to determine what traffic will be allowed across, as this might cause serious problems for SA establishment, especially for mobile IP case. However, the proposed solution is pretty complex and there are easier approaches to dealing with this problem in the mobile IP case, e.g., co-locating FAs and HAs with firewalls, or establishing long term SAs, between HAs and FAs and their local firewalls, to facilitate forwarding of mobile IP traffic. Ran Atkinson spoke about the standards process and it's applicability to the IPSEC RFCs. Because some of the 1825-29 RFCs are being replaced, and because all of them cross reference one another, the group cannot be advanced from Proposed Standard to Draft Standard until 6 months elapses after the last of the inter-related documents have been updated. Ran also discussed his revised IPSEC Security Architecture document, a replacement for RFC-1825. Steve Kent suggested that the WG revisit AH to remove its two-different modes of use, given the new ESP options that incorporate autehntication and thus obviate the need for the embedded AH mode (ESP followed directly by AH). Steve also suggested that the WG revise ESP to add in optional, variable length fields for IVs, integrity checks, etc. so that the transform documents are independent of one another and don't grow geometrically as new algorithms are added. The WG adopted both suggestions and Steve Kent agreed to work with the WG co-chairs to provide suitable text for the revised RFCs. Session 2, Wednesday: Key Management Issues Bob Moskowitz (Chrysler) challenged the group to solve a network layer security problem for communication among automotive parts suppliers and manufacturers, but with a lot of nasty residual problems, e.g., misuse of net numbers by particiants, diverse set of existing firewalls, etc. Bob's goal is to start deploying IPsec by the end of 1996. Ashar Aziz presented SKIP. Note the use of the SKIP header between IP header and AH or ESP. Two modes of use: the first mode has no setup messages once the master keys are in place, no Perfect Forward Secrecy, and has significant per-message overhead. This mode relies on pre- positioned D-H master keys from which unicast keys are derived. The second mode uses ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with approximate PFS, anonymity, etc. Claimed multicast mode support is based on a group co-ordinator creating a group key (distribution of the private key to group members is not described here and is potentially hard to implement or scale) which the sender uses as the target for Diffie-Hellman computation. Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and are being fixed in the next draft. Ashar pushed for adoption of the certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs as well as certificates, not just X.509 certificates, but PGP too. Doug Maughan reported on ISAKMP. Free software is available via MIT server at http://web.mit.edu/network/isakmp. cisco has also worked on an ISAKMP with Oakley implementation, also freely available from cisco and MIT web sites. There is also an implementation by the UK Defence Research Agency. ISAKMP provides very general KMP framework, capable of supporting various key exchange algorithms, authentication, security association management, and denial of service protection. Recent I-D changes: moved from request/response to chained payload format (for better performance and/or more flexible for multi-exchange protocols), can negotiate multiple SPIs at the same time (for greater efficiency and flexibility), and an expanded set of authentication payload types (for better support of more exchnage types). Format is more complex now, because of support of multiple paylodas per message, negotiating multiple protocols at one time, etc. See version 5 specification I-D for details. Jon Millen's analysis notes that cookies don't buy much Denial- of-Service protection, and that authentication and key exchange is sufficiently decoupled to require further analysis. Interoperability testing, using Oakley, is now going on between cisco and DRA. Work will continue to add other key exchange algorithms, commercial and government. Hilarie Orman described Oakley briefly. Oakley is quite flexible: can use Diffie-Hellman exchange and/or pre-positioned keys or Public Key (RSA) encryption ; authentication via RSA encryption, signatures or predistributed shared secrets; integrity is available but can be omitted, and Perfect Forward Secrecy is available but can be omitted. Minimal message exchange is 3 messages, though more round-trips can also occur. She has also published the group paramaters for several bases, yielding 90-bit strength key outputs. ISAKMP integration is almost complete. She suggested having the ESP and AH transforms define how the necessary key bits are extracted from the output of the Oakley computation. Basically, a general collection of modules that can meet lots of different requirements, using a consistent syntax. Dan Harkins reported on the status of the ISAKMP-Oakley integration effort. A new Internet-Draft is out with a coherent profile of ISAKMP and Oakley when used together. The first two ISAKMP messages establish an SA, then the parties negotiate SAs for their clients. Four modes of Oakley are specified: Main Mode (for ISAKMP phase 1 exchange, four messages); Agressive Mode (quick, but no identity protection, an alternate phase 1 exchange in 3 messages); Quick Mode ( a phase 2 exchange, in 3 messages, but can be repeated multiple times after a phase 1 exchange); Group Mode (for changing from one group to another, over time). cisco's free ISAKMP+Oakley code will be implementing this specification. Hugo made some comments on Oakley/ISAKMP. He likes the overall framework, but sees a need to refine the specs to remove some ambiguity and facilitate interoperability. From a cryptographic standpoint he has some suggestions, but lacked time to go into details. From a capability perspective, he would like to see a support for pre- positioned or centrally-distributed symetric keys, with PFS, which Oakley does allow. cisco has indicated that they would accommodate that request. Hugo doesn't like the reliance on Diffie-Hellman in the new Oakley/ISAKMP profile, relative to the broader capabilities of Oakley. Finally, Hugo expressed some concerns about the differences in types of attacks one might mount in the public key vs. symmetric key arena. The bottom line is that the ISAKMP and Oakley protocols accommodate all of these suggestions, it's just an issue of of getting the cisco implementation to incorporate these features. Very brief, surprizing comments from John Gilmore, announcing that he has purchased all of Bill Simpson's rights, including copyright, for Photuris, to ensure that it is considered as a viable contender in the key management protocol sweepstakes. However, he has not obtained any rights to Photuris from Phil Karn. Further, there is no new draft available addressing the previously discussed deficiencies of Photuris. There was no evidence of broad support for Photuris at this meeting. There was a short talk on Eliptical Curve Cryptography (ECC) technology, for both Diffie-Hellman exchanges and DSA- & RSA- equivalent (signature with recovery, but not excatly RSA) signautues. A major benefit is that shorter key lengths are security equivalent to larger key lengths. The IEEE P1363 specifications were mentioned and there was some discussion of patents relative to the use of ECC. There are some ECC-related patents, in addition to the general public key patent, but they relate mostly to implementations not to the basic math. The speaker is from Certicom, which holds some of these implementation patents. Closing discussions were process oriented, i.e., how will the WG decide what will become the default key management standard for IPSEC ? Jeff Schiller conducted straw polls which showed significant differences of opinion between Oakley/ISAKMP and SKIP, although everyone wants a quick resolution to the issue! Jeff suggests having a special committee come back with a justifiable resolution.