Minutes of the IPSEC working group meeting Wednesday, March 20, 2002, 15:30 -- 17:30 CBC Oracle Attack ================= Eric Rescorla gave a presentation on an chosen plaintext attack on CBC. In order to carry it out, the attacker can inject traffic on the clear side, be able to read traffic on the encrypted side, the CBC IV must be predictable, and the attacker can control first block of ciphertext. Some systems are believed vulnerable: Older KAME-based with weak RNG, FreeSwan with predictable IV. AES Cipher documents ==================== Sheila Frankel gave an update on the NIST AES documents. AES XCBC now has some sample vectors and changed the algorithm description to eliminate ambiguities. This should be ready to advance. The other two drafts were not updated for this meeting. AES CBC draft needs sample vectors. They have changed the IV’s to be random. SHA 256 draft will also have test vectors included. Both drafts will be updated in the next two weeks. SLIDES: 01.Mcgrew-Counter-Mode-and-IPsec.pdf David McGrew presented a generalized integer counter mode draft that brought together the various counter mode drafts that have appeared in various IETF groups. During discussions, Steve Kent brought up a couple of issues with IVs sequence numbers. New versions of ESP/AH ====================== SLIDES: 02.Kent_New_ESP_slides1.ppt Steve Kent gave a presentation which discussed updates to the new versions of ESP/AH. We still need to need to decide on mandatory algorithms. IP storage group is going to get their documents in with ESP1, so they shouldn’t be pressuring. They’re using 3DES CBC as the MUST. A second algorithm may be counter mode. Someone mentioned a dual use mode that is unencumbered and is being used in the 802.11. Question about whether Russ’ draft is suitable for IP storage. Dave McGrew mentioned that there are combined modes that are no IP encumbered. Someone asked why XCBC wasn’t also an easy choice. It handles variable length packets, but variable length packets can also be dealt with by adding the length to the packet. Discussion will be taken to the list. AH clarifications and Changes: question about sharing SAs with separate sequence space per sender. This would support some of the multicast needs. This will need to be discussed on the list. There was a discussion about whether or not AH should be deprecated. Cheryl Madson pointed out that if we’re trying to get rid of AH, we need to concerned about other groups like VRRP. Ted suggests that we should perform a formal consensus call on the list about deprecated AH. An informal pool of the room indicated that most people were in favor of discarding it. Steve commented that we’re discussing deprecating AH as an IPsec requirement. It could still have a life as an independent protocol. Mark B. from v6 group has asked for help in writing the host requirements for IPsec (v6 end system profile). One comment was the IDS vendors who quickly look at the packet and if ESP they assume it’s encrypted, if AH they know it’s not. Dave Black mentioned that in IP storage they had been working through a detailed profile for IPsec. Come find Dave if you’re interested in helping them. Steve kent then spent some time discussion changes to RFC 2401. This will require a much more extensive rewrite than it was for ESP. Planned changes include restricting traffic selection to a single scheme, namely address ranges; change in the outbound and inbound processing to use caches. Expect AH doc to easily go forward due to fewer changes, ESP next, and 2401 ready by Yokahama. IANA and IPSEC Registry issues ============================== SLIDES: 03.Hoffman_IANA_registries.ppt Paul Hoffman discovered there are a number of descrepancies and missing things in the IANA's IPSEC registry. A proposal for changes will be sent around. Discussion on http://www.vpnc.org/iana-ipsec/ This is an addition and completion exercise, not a deletion one. NAT Traversal ============= Brian Swander described the various issues and what breaks with current drafts. In order to get through existing deployed NATs, must use something other than port 500. Presentation included a table of the testing they’ve done against 13 NAT vendor boxes and proposed asolution that would float the port numbers if a NAT is present. According to Brian this gives us a better encapsulation format. Brian did not think that fragmentation should be addressed in NAT Traversal. Discussion was raised about whether we should worry about this or wait until SOI. The chair said we were hoping for a fix for current deployments. IPSEC Transport Mode ==================== SLIDES: 04.touch-ietf-3-02-ipsec.ppt Joe Touch gave an update on his document which describes the use of IPsec transport mode in hop by hop routing scenarios. Tunnel mode IPsec interferes with hop by hop routing which is used for IPsec’d VPN links. They are integrating final clarifications, should have final draft in the next 1.5 weeks and will be submitted to informational RFCs. Email touch@isi.edu if you have input or questions. Steve Kent asked how big a problem this is. Answer: has significant impact to provider provisions IPsec VPNs. IPSEC properties ================ SLIDES: 05.krywaniuk-ipsec-properties.ppt Andrew Krywaniuk: IPsec properties: Discussed existing IPsec/IKE and associated problems. The purpose is to assist current IKE deployments while SOI is under construction, and perhaps to provide input to SOI efforts. Announcements ============= Hugh Daniels announced that Free Swan team put up an IPsec gateway here at the IETF, and is willing to hook up anyone’s client machine to encrypt traffic on wireless LAN. Minutes of the IPSEC working group meeting Thursdaym, March 21, 2002, 9:00 -- 11:30 Opening comments by the chairs. Elliptical Curves ================= Hilliary Orman asked that the working group consider whether or not EC algorithms should be included in IPSEC. She asked that folks continue an engineering discussion on the list. The primary concern is over the patent issues. Charlie said he thought whether this succeeds or fails is when someone ships a product and others see it’s possible. IP Storage ========== David Black gave an update on the progress of the IP Storage working group. They wish to use tunnel mode. SA selector will be the destination address, TCP protocol, single TCP port (magic number 3260). David asked how many implementations supported this set of SA selectors. TCP protocol is not part of the Freeswan stack but there were other vendors in the room that support this selector. The VPNC conformance test also tests for single port support. Miscellaneous SOI Requirements ============================== SLIDES: 06.hoffman-misc-reqs.ppt Paul Hoffman summarized mailing list conversations on SOI requirements. He covered six topics: 1) Identity protection: general discussion was that people wanted to protect both parties. 2) Addresses in the traffic selectors. There are a number of ways of doing it in v1. Still actively discussed on the list. Are we going to have them, and if so are we going to simplify it and how. 3) support for multiple algorithms. 4) should vs may for EC. It’s been barely tested. Thinks that most implementers understand RSA, but may not understand EC. On the list, it seemed that "may" be ok. 5) Error processing for setting up Sas. Both proposals are deficient in this area and need more detail. 6) Do we need a phase 2. Discussion converged on how we handle QOS. This is a topic that a fair number of people on the list don’t understand. Need for fast keying fits in here. Do you need a management channel for Sas is another issue. The purpose of phase 2 is sometimes lost on some users. We need to describe what and why. Next steps: read and comment on Cheryl’s requirements document. Bring issues to the mailing list. SOI Requirements document ========================= SLIDES: 07.Madson-Son-of-IKE-Requirements.pdf Cheryl Madson discussed updates to the Son-of-Ike Requirments document. The draft is currently at vpnc.org but will be submitted to Ids. The document now includes scenarios, security operational and policy requirements. Intent of scenarios is to help scope and drive the SOI protocol. Some of the key requirements for these areas are: 1) scalability needs to work for both very small and very large systems; fast setup cost based on both the number of messages, amount of cpu processing. Need to include the cost of authentication which has been somewhat overlooked in the past. Needs to be both fast and low delay; 2) one phase vs two phases: there will be multiple IPsec connections between a pair of IPsec endpoints. Inside address assignment has to happen somewhere. 3) something needs to guarantee the operational integrity of "tunnel management channel". Primary goal is to ensure protocol convergence. 4) protocol requirements, including protocol interactions (e.g., IPSP), Identity, Interaction with NAT, general design criteria; reasonable modularity, scalability. 5) Policy requirements: provisioning and management; additional per-connection policy including inner address assignment, identify absolute minimum for bootstrap/let another protocol handle the rest; expanding the selector set (QoS DSCP, VPN tags, list of selector entries); SPD selectors and dynamic policy. Another policy issue centers on retaining Sas in the face of address changes. Not specific to SOI but may play with mobile IP in future. 6) Authorization requested help to identify specific requirements. 7) Security requirements: key agreement, key generation, authentication. Next steps include further elaboration of scenarios where it will be used, flesh out the requirements, then weigh the relative importance of various requirements and a means of resolving conflicts. IKE V2 Update ============= SLIDES: 08.radike2.ppt Radia Perlman presented the changes in the IKEv2 document: *) IKE V2 now sign what you send plus the other guys nonce, and uses different keys in the different directions. *) The source port is permitted to be not equal to 500 for NATs *) Allow preshared secret keys are now allowed. *) Decided to keep 4 msgs +2 for stateless cookie *) negotiate crypto suites than separate algs. There was pushback on suites *) added Bill Summerfield’s birth cert., A monotonically increasing counter every time you crash and come back up. *) Me Jane you Tarzan which was the number one request in SSL. This is useful when Bob’s IP address can be hosting a lot of different ids. There is an open question about whether the identity information should be put in message 1 or message 3. *) Fragmentation scheme was included. JFK Update ========== SLIDES: 09.jfk-talk.pdf Angelos Keromytis gave an update on the JFK document (draft-ietf-ipsec-jfk-01.txt) Angelos reviewed the JFKr (called LBJ at last IETF) key exchange. JFKr is more what the working group prefers. The draft 01 includes some text on proof of security. SA deletion, rationale for no phase 2, and added text on SA negotiations with ciphersuites, and only used ranges for traffic selectors. To come: Ipi added in authenticator; CERT verification result caching (not specific to JFK), Jane/Tarzan with msg 3, speedup of rekeying, fragmentation attack avoidance possible with 4 messages, easy computation DoS/flash-crowd management. Preshared key authentication is possible but not in the draft. Still questioning whether these are really needed. Said there were claims on the list, but no facts. Comparison of IKEv2, JFK, and SOI Requirements ============================================== Charlie Kaufman discussed how the IKEv2 and JFK compared against the SOI requirements Noncontentious issues: * simplicity * fully specified for interoperability in a single doc, * use 4 messages to set up an ESP connection Contentious Issues: Forward and backward compatibility: IKEv2 designed to run over the same UDP port as ikev1. Differing opinions as to whether this is good or bad. IKEv2 has a lot of stuff for future compatibility. Whether or not to allow proprietary extensions. Crypto Negotiation: one question is why do you want to negotiate it? Once answer is to allow smooth transition to a new one. Ideally want to function while one is upgraded and the other isn’t. Currently, IKEv2 initiator gives a list and responder chooses. In JFK, phase 1 DH responder says what it can handle and the initiator chooses. In the other algs, resonder declares. IKEv2 inherits long list of variations from IKEv1. In JFK starts with a few variations. Another issue is whether we want to do negotiations with suites or a la carte. (comment: TLS has problems with suites, need a policy about how to construct the suites. Third option to allow the combinatorial explosion but we also come up with a group of suites. This makes it easy for end user. One way or the other there is the combinatorial explosion and it takes time to test the combinations. So, select what you’re going to test and make those available. Uri: suites are preferable for analyses. ) One or two phases: issues hidden under this: 1)IKE crypto separate from ESP/AH (both proposals say yes); 2)whether you can establish multiple ESP/AH Sas via a single IKE SA: IKEv2-yes; JFK-no. Some people really want to do this, others don’t. (Comment: Steve Kent: 2401 talks about nested security associates, transport SA inside a tunnel SA.) 3)how to do dead peer detection: Could have put it in ESP/AH but didn’t so now need to keep it within IKE. IKEv2 does it within IKE; JFK has suggestions, but unspecified. How Many Messages: IKEv2 and JFK both say 4, but each may need more based on circumstances. Not really much difference. (comment: the customer base only cares about the number of message in that it impacts the users experience of tunnel setup. There are other things that impact user experiences that need to be addressed.) Identity hiding: Alice from passive, Bob from all: both IKEv2 and JFKr; Alice from active, Bob from none: JFKi. May be other options. Plausible Deniability: Might be able to prove that somebody had a conversation with somebody else. IKEv2 and JFKr have it, but JFKi doesn’t ESP/AH/Ipcomp: IKEv2:any combo negotiated together; JFK ESP or AH. Don’t know where Ipcomp fits in. PKI-less operation: Do we support pre-shared keys? UDP Encapsulation & NATs: IKEv2 accidentally broke could be easily fixed. JFK by disallowing extensions, it would be challenging to negotiate. Changes from IKEv1: do not negotiate between tunnel and transport modes; (comment: this may not be as straight forward as stated, there are gremlins.) removed lifetime; genealize transport selectors; removed DOI/security labels. You Tarzan, Me Jane: Incompatible with SSL/TLS; should we allow it in IKE? If so, should it be in msg 1 or 3? IKE/JFK Announcement ==================== Matt Blaze and Radia Perlman announced that members of the IKE and JFK design teams met last night to try to resolve differences. They shared same goal of designing the most sensible protocol that meets the needs of the group. Will produce a document by the end of April which outlines various protocol properties and the implications of the; and compatibility between the properties. Example of identity protection, plausible deniability, DOS, fragmentation cookies, etc. Then we will need a focused discussion about what choices we need. We will try to complete discussion by end of May and get a draft by Yokahama meeting that summarizes the group’s consensus.