[IPsec] Proposed wording for rechartering the IPsecME WG

[Paul Hoffman <[e-mail]>]

Greetings again. Yaron and Pasi and I have put our heads together on the seven proposed new work items for the WG. Of the seven, we propose that four go ahead as WG work items and three not; see the descriptions below.

We will turn in this proposed rechartering within a week, but are quite open to changes to the proposed charter wording for the proposed work items.

=====
Quick Crash Discovery (QCD) for IKEv2

Proposed charter text:

An IKEv2 standards-track 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.

=====
EAP-only IKEv2

Proposed charter text:

The WG will develop 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.

=====
Password-based mutual authentication for IKEv2

Proposed charter text:

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.

=====
High Availability/Load Sharing 

Proposed charter text:

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.

=====
Childless SAs

It is our view that this proposal doesn't make IPsec work better (or even differently) in any user-perceived way. The specification looks almost ready, and does not need any IANA assignments, so we encourage the authors to progress it as an individual submission for standards track instead of a WG work item.

=====
WESP Extension Framework / Concrete Extensions

The recent discussion of WESPv1 shows that there are a fair number of surprising views on where and how WESP is expected to be used. It is too soon to charter this work. Having a solid set of proposed extensions and a framework for how WESPv2 could be used to handle them would be needed before the WG could decide on taking this work in.

=====
Labelled IPsec

This one did not have sufficient interest or agreement exactly what should be done. It could come up again later, but more work would need to be done to help the WG understand the work that precedes it and the expected use cases.

--Paul Hoffman, Director
--VPN Consortium