2.7.3 IP Security Maintenance and Extensions (ipsecme)

NOTE: This charter is a snapshot of the 77th IETF Meeting in Anaheim, California USA. It may now be out-of-date.

Last Modified: 2010-02-24

Chair(s):

Paul Hoffman <paul.hoffman@vpnc.org>
Yaron Sheffer <yaronf.ietf@gmail.com>

Security Area Director(s):

Sean Turner <turners@ieca.com>
Tim Polk <tim.polk@nist.gov>

Security Area Advisor:

Sean Turner <turners@ieca.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:

Done  WG last call on IPv6 configuration payloads
Done  WG last call on IPsec roadmap
Done  WG last call on session resumption
Done  WG last call on redirect
Done  WG last call on IKEv2bis
Done  WG last call on ESP NULL traffic visibility
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

Internet-Drafts:

  • draft-ietf-ipsecme-ikev2bis-11.txt
  • draft-ietf-ipsecme-roadmap-06.txt
  • draft-ietf-ipsecme-aes-ctr-ikev2-07.txt
  • draft-ietf-ipsecme-ipsec-ha-04.txt
  • draft-ietf-ipsecme-eap-mutual-03.txt

    Request For Comments:

    RFCStatusTitle
    RFC5685 PS Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
    RFC5723 PS Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
    RFC5739 E IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
    RFC5840 PS Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
    RFC5879 I Heuristics for Detecting ESP-NULL Packets

    Meeting Minutes


    Slides

    Agenda and beginning of meeting notes
    IPsec HA
    Mutual EAP Authentication
    Failure detection overview
    PAKE Selection Criteria
    PAKE process