Current Meeting Report
2.5.2 IP Security Protocol (ipsec)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
Barbara Fraser <email@example.com>
Theodore Ts'o <firstname.lastname@example.org>
Security Area Director(s):
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Security Area Advisor:
Jeffrey Schiller <email@example.com>
Uri Blumenthal <firstname.lastname@example.org>
To Subscribe: email@example.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec
Description of Working Group:
Note: The Technical Advisor has the task to advice on technical
matters related to all the MIB work in this WG.
Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.
The IPSEC working group will restrict itself to the following
short-term work items to improve the existing key management protocol
(IKE) and IPSEC encapsulation protocols:
1. Changes to IKE to support NAT/Firewall traversal
2. Changes to IKE to support SCTP
3. New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
a fast AES mode suitable for use in hardware encryptors
4. IKE MIB documents
5. Sequence number extensions to ESP to support an expanded sequence
6. Clarification and standardization of rekeying procedures in IKE.
The working group will also update IKE to clarify the specification and
to reflect implementation experience, new requirements, and protocol
analysis of the existing protocol. The requirements for IKE V2 will be
revised and updated as the first step in this process.
Goals and Milestones:
|Done||  || Post as an Internet-Draft the IP Security Protocol.|
|Done||  || Post as an Interenet-Draft the specification for Internet key management.|
|Done||  || Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.|
|Done||  || Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH).|
|Done||  || Submit revised Interent-Drafts for ESP, AH, and IP Security Architecture.|
|Done||  || Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.|
|Done||  || Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard.|
|Done||  || Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.|
|Oct 01||  || Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call.|
|Oct 01||  || Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards.|
|Nov 01||  || Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed.|
|Dec 01||  || Internet-Draft on IKE v2 Requirements to working group last call|
|Dec 01||  || Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call.|
|Dec 01||  || Internet-Drafts describing candidate IKE v2 approaches submitted to the working group.|
|Feb 02||  || Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards.|
|Apr 02||  || Discuss and select the IKE v2 design from candidate approaches.|
|Sep 02||  || IKE|
|Dec 02||  || Submit|
Request For Comments:
|RFC1828||PS||IP Authentication using Keyed MD5
|RFC1829||PS||The ESP DES-CBC Transform
|RFC2104|| ||HMAC: Keyed-Hashing for Message Authentication
|RFC2085||PS||HMAC-MD5 IP Authentication with Replay Prevention
|RFC2401||PS||Security Architecture for the Internet Protocol
|RFC2410||PS||The NULL Encryption Algorithm and Its Use With IPsec
|RFC2411|| ||IP Security Document Roadmap
|RFC2402||PS||IP Authentication Header
|RFC2412|| ||The OAKLEY Key Determination Protocol
|RFC2451||PS||The ESP CBC-Mode Cipher Algorithms
|RFC2403||PS||The Use of HMAC-MD5-96 within ESP and AH
|RFC2404||PS||The Use of HMAC-SHA-1-96 within ESP and AH
|RFC2405||PS||The ESP DES-CBC Cipher Algorithm With Explicit IV
|RFC2406||PS||IP Encapsulating Security Payload (ESP)
|RFC2407||PS||The Internet IP Security Domain of Interpretation for
|RFC2408||PS||Internet Security Association and Key Management
|RFC2409||PS||The Internet Key Exchange (IKE)
|RFC2857||PS||The Use of HMAC-RIPEMD-160-96 within ESP and AH
Current Meeting Report
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.
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
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
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.
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
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 firstname.lastname@example.org if you have input or questions. Steve Kent asked how big a problem this is. Answer: has significant impact to provider provisions IPsec VPNs.
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.
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.
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.
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
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
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
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.
Angelos Keromytis gave an update on the JFK document
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
* fully specified for interoperability in a single doc,
* use 4 messages to set up an ESP connection
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?
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.
Comparison Of IKEv2, JFK, and SOI Requirements
IKEv2 Changes and Rationale
Son of IKE Requirements
ESP v2, AH v2 2401bis
Updating the IPsec registries in IANA
IPsec Transport Mode for Dynamic Routing
Miscellaneous successor-to-IKE requirements discussion
Counter Mode and IPsec ESP
Just Fast Keying (JFK)