[IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)

[Paul Hoffman <[e-mail]>]

Comments should be sent to all of this list, the IESG, and the IAB.

--Paul Hoffman

>From: IESG Secretary <[e-mail]>
>To: [e-mail], [e-mail], [e-mail], [e-mail]
>Subject: Internal WG Review: Recharter of IP Security Maintenance and
>         Extensions (ipsecme)
>reply-to: [e-mail]
>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 ([e-mail])
>    * Yaron Sheffer ([e-mail])
>
>Security Area Director(s):
>    * Tim Polk ([e-mail])
>    * Pasi Eronen ([e-mail])
>
>Security Area Advisor:
>    * Pasi Eronen ([e-mail])
>
>Mailing Lists:
>  General Discussion: [e-mail]
>  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