[MIB-DOCTORS] FW: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)

["Romascanu, Dan (Dan)" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
IESG Secretary
Sent: Tuesday, February 09, 2010 9:00 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: WG Review: Recharter of IP Security Maintenance and Extensions
(ipsecme) 

A modified charter has been submitted for the IP Security Maintenance
and Extensions (ipsecme) working group in the Security Area of the IETF.
The IESG has not made any determination as yet.  The modified charter is
provided below for informational purposes only.  Please send your
comments to the IESG mailing list ([e-mail]) by Tuesday, February
16, 2010.

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