The IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. IP Security Maintenance and Extensions (ipsecme) --------------------------------------------------- Current Status: Active Working Group Chair(s): * Paul Hoffman <paul.hoffman@vpnc.org> * Yaron Sheffer <yaronf@checkpoint.com> Security Area Director(s): * Tim Polk <tim.polk@nist.gov> * Pasi Eronen <pasi.eronen@nokia.com> Security Area Advisor: * Pasi Eronen <pasi.eronen@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. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for "weak" shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
