Comments should be sent to all of this list, the IESG, and the IAB. --Paul Hoffman
>From: IESG Secretary <iesg-secret...@ietf.org> >To: i...@ietf.org, i...@iab.org, paul.hoff...@vpnc.org, yar...@checkpoint.com >Subject: Internal WG Review: Recharter of IP Security Maintenance and > Extensions (ipsecme) >reply-to: i...@ietf.org >Date: Tue, 26 Jan 2010 12:30:02 -0800 (PST) > >A new charter for the IP Security Maintenance and Extensions (ipsecme) >working group in the Security Area of the IETF is being considered. The >draft charter is provided below for your review and comment. > >Review time is one week. > >The IETF Secretariat > >IP Security Maintenance and Extensions (ipsecme) >--------------------------------------------------- >Current Status: Active Working Group >Last Modified: 2010-01-21 > >Chair(s): > * Paul Hoffman (paul.hoff...@vpnc.org) > * Yaron Sheffer (yar...@checkpoint.com) > >Security Area Director(s): > * Tim Polk (tim.p...@nist.gov) > * Pasi Eronen (pasi.ero...@nokia.com) > >Security Area Advisor: > * Pasi Eronen (pasi.ero...@nokia.com) > >Mailing Lists: > General Discussion: ipsec@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec > Archive: http://www.ietf.org/mail-archive/web/ipsec/ > >Description of Working Group: > >The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated >RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec >security architecture (RFC 4301). IPsec is widely deployed in VPN >gateways, VPN remote access clients, and as a substrate for >host-to-host, host-to-network, and network-to-network security. > >The IPsec Maintenance and Extensions Working Group continues the work >of the earlier IPsec Working Group which was concluded in 2005. Its >purpose is to maintain the IPsec standard and to facilitate discussion >of clarifications, improvements, and extensions to IPsec, mostly to >IKEv2. The working group also serves as a focus point for other IETF >Working Groups who use IPsec in their own protocols. > >The work items are: > >- A standards-track IKEv2 extension that allows an IKE peer to quickly >and securely detect that its opposite peer, while currently reachable, >has lost its IKEv2/IPsec state. Changes to how the peers recover from >this situation are beyond the scope of this work item, as is improving >the detection of an unreachable or dead peer. Ideas from >draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used >as starting points. > >- A standards-track IKEv2 extension to allow mutual EAP-based >authentication in IKEv2, eliminating the need for the responder to >present a certificate. The document will define the conditions that >EAP methods need to fulfill in order to use this extension. The >document will recommend, but will not require, the use of EAP methods >that provide EAP channel binding. The proposed starting point for this >work is draft-eronen-ipsec-ikev2-eap-auth-07.txt. > >- IKEv2 supports mutual authentication with a shared secret, but this >mechanism is intended for "strong" shared secrets. User-chosen >passwords are typically of low entropy and subject to off-line >dictionary attacks when used with this mechanism. Thus, RFC 4306 >recommends using EAP with public-key based authentication of the >responder instead. This approach would be typically used in enterprise >remote access VPN scenarios where the VPN gateway does not usually >even have the actual passwords for all users, but instead typically >communicates with a back-end RADIUS server. > >However, user-configured shared secrets are still useful for many >other IPsec scenarios, such as authentication between two servers or >routers. These scenarios are usually symmetric: both peers know the >shared secret, no back-end authentication servers are involved, and >either peer can initiate an IKEv2 SA. These features make using EAP >(with its strict client-server separation) undesirable. > >The WG will develop a standards-track extension to IKEv2 to allow >mutual authentication based on "weak" (low-entropy) shared >secrets. The goal is to avoid off-line dictionary attacks without >requiring the use of certificates or EAP. There are many >already-developed algorithms that can be used, and the WG would need >to pick one that both is believed to be secure and is believed to have >acceptable intellectual property features. The WG would also need to >develop the protocol to use the chosen algorithm in IKEv2 in a secure >fashion. It is noted up front that this work item poses a higher >chance of failing to be completed than other WG work items; this is >balanced by the very high expected value of the extension if it is >standardized and deployed. > >- IPsec gateways are often deployed in clusters that look like a >single gateway to the peer (such as for high availability and load >balancing reasons). However, correctly maintaining the appearance to >the peer of a single gateway is complicated; one of the main >challenges is the strict use of sequence numbers both in IKEv2 and >ESP/AH. > >This work item will define a problem statement and requirements for >potential IPsec/IKEv2 mechanism (or multiple mechanisms) to simplify >cluster implementations. The result will be an informational document >that, once completed, may lead to chartering one or more new work >items to specify the actual mechanisms. The scope is restricted to >mechanism(s) that are visible to the peer, and thus usually require >interoperability between vendors. Mixed-vendor clusters, and protocols >between the cluster members, are explicitly out of scope of this work >item. The starting point will be draft-nir-ipsecme-ipsecha-00. > > >In addition, the following items from the existing charter are >expected to be completed soon: > >- A revision to IKEv2 (RFC 4306) that incorporates the clarifications >from RFC 4718, and otherwise improves the quality of the >specification, taking into account implementation and interoperability >experience. In some cases, the revision may include small technical >corrections; however, impact on existing implementations must be >considered. Major changes and adding new features is beyond the scope >of this work item. One part of this work item, clarifying how AES >counter mode is used for the IKEv2 encrypted payload, is in a separate >document. > >- An IPsec document roadmap that describes the various RFC documents >covering IPsec, including both the core RFC 240x and RFC 430x versions >of IPsec, and extensions specified in other documents. This document >will be informational. > >- A standards-track mechanism that allows an intermediary device, such >as a firewall or intrusion detection system, to easily and reliably >determine whether an ESP packet is encrypted with the NULL cipher; and >if it is, determine the location of the actual payload data inside the >packet. > > >The scope of the WG is restricted to the work items listed above. The >WG shall not consider adding new work items until there are four or >fewer documents being actively worked on (not yet progressed to IETF >Last Call). At that time, the WG can propose rechartering. > >Work on IPsec extensions that are not included in this charter can >happen as usual in other WGs, or as individual submissions. > >This charter will expire in February 2012 (24 months from >approval). If the charter is not updated before that time, the WG will >be closed and any remaining documents revert back to individual >Internet-Drafts. > >Goals and Milestones: > >Aug 2010 - WG last call on HA requirements >Dec 2010 - WG last call on quick crash discovery >Jan 2011 - WG last call on EAP-only authentication >Mar 2011 - WG last call on password-based authentication _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec