Current Meeting Report
Slides


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: 05-Feb-02
Chair(s):
Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Technical Advisor(s):
Uri Blumenthal <uri@lucent.com>
Mailing Lists:
General Discussion:ipsec@lists.tislabs.com
To Subscribe: ipsec-request@lists.tislabs.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 number space.

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
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC1828PSIP Authentication using Keyed MD5
RFC1829PSThe ESP DES-CBC Transform
RFC2104 HMAC: Keyed-Hashing for Message Authentication
RFC2085PSHMAC-MD5 IP Authentication with Replay Prevention
RFC2401PSSecurity Architecture for the Internet Protocol
RFC2410PSThe NULL Encryption Algorithm and Its Use With IPsec
RFC2411 IP Security Document Roadmap
RFC2402PSIP Authentication Header
RFC2412 The OAKLEY Key Determination Protocol
RFC2451PSThe ESP CBC-Mode Cipher Algorithms
RFC2403PSThe Use of HMAC-MD5-96 within ESP and AH
RFC2404PSThe Use of HMAC-SHA-1-96 within ESP and AH
RFC2405PSThe ESP DES-CBC Cipher Algorithm With Explicit IV
RFC2406PSIP Encapsulating Security Payload (ESP)
RFC2407PSThe Internet IP Security Domain of Interpretation for ISAKMP
RFC2408PSInternet Security Association and Key Management Protocol (ISAKMP)
RFC2409PSThe Internet Key Exchange (IKE)
RFC2857PSThe 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.

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.

Slides

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
IPsec Properties
Miscellaneous successor-to-IKE requirements discussion
Counter Mode and IPsec ESP
Just Fast Keying (JFK)