[secdir] are IPsec/IKE MUST or SHOULD implement for IPv6

"Laganier, Julien" <julienl@qualcomm.com> Tue, 20 July 2010 23:00 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422B33A68D5 for <secdir@core3.amsl.com>; Tue, 20 Jul 2010 16:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwt2crMqwACu for <secdir@core3.amsl.com>; Tue, 20 Jul 2010 16:00:46 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 66C0C3A65A5 for <secdir@ietf.org>; Tue, 20 Jul 2010 16:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279666860; x=1311202860; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"secdir@ietf.org"=20<secdir@ietf.org>|Date:=20Tue, =2020=20Jul=202010=2016:00:40=20-0700|Subject:=20are=20IP sec/IKE=20MUST=20or=20SHOULD=20implement=20for=20IPv6 |Thread-Topic:=20are=20IPsec/IKE=20MUST=20or=20SHOULD=20i mplement=20for=20IPv6|Thread-Index:=20AcsoUnHYpLxB809CR3+ ghsOW84CqmwADK+PA|Message-ID:=20<BF345F63074F8040B58C00A1 86FCA57F1F6688501C@NALASEXMB04.na.qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=gRwLvrg7gmrM+PXHGHRCMRw27GducjRk0wq6MIS84SE=; b=jTLXO/tancapWvyj7T966SMQ4GqmTa8CHUxo4MfDyS42fxFroKi0NdDP tNpAiqO6OZxyZXjep9fpTr+n1zenvgteT0dMOtHt9TThnC65XIx+fk3nd FrCSTOpSGonOeVsjm+tCHjDa7LAj7D3ulGZE8uzeC+XdQ2k/gzBwpA+nM Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,6049"; a="48096499"
Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 20 Jul 2010 16:00:40 -0700
X-IronPort-AV: E=Sophos;i="4.55,232,1278313200"; d="scan'208";a="44857943"
Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jul 2010 16:00:40 -0700
Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 16:00:41 -0700
Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 20 Jul 2010 16:00:42 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Tue, 20 Jul 2010 16:00:42 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Date: Tue, 20 Jul 2010 16:00:40 -0700
Thread-Topic: are IPsec/IKE MUST or SHOULD implement for IPv6
Thread-Index: AcsoUnHYpLxB809CR3+ghsOW84CqmwADK+PA
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F6688501C@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] are IPsec/IKE MUST or SHOULD implement for IPv6
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jul 2010 23:00:48 -0000

FYI, ongoing discussion just started in 6man.

--julien

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: Tuesday, July 20, 2010 2:27 PM
To: ipv6@ietf.org
Subject: Node Requirements: Issue 17 - IPsec/IKE

Folks,

A revised version of draft-ietf-6man-node-req-bis-05.txt has been
published, but it's Security section needs work. In particular, the WG
needs to answer the following questions:

 - Should IPsec be a SHOULD or MUST?
 - What about IKEv2?

Let me start with some background:

RFC 4294 says the following:

> 8.  Security
> 
>    This section describes the specification of IPsec for the IPv6 node.
> 
> 8.1.  Basic Architecture
> 
>    Security Architecture for the Internet Protocol [RFC-4301] MUST be
>    supported.
>
> 8.2.  Security Protocols
> 
>    ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.

...

> 8.4.  Key Management Methods

>    An implementation MUST support the manual configuration of the
>    security key and SPI.  The SPI configuration is needed in order to
>    delineate between multiple keys.
> 
>    Key management SHOULD be supported.  Examples of key management
>    systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include
>    key management functions.
> 
>    Where key refresh, anti-replay features of AH and ESP, or on-demand
>    creation of Security Associations (SAs) is required, automated keying
>    MUST be supported.
> 
>    Key management methods for multicast traffic are also being worked on
>    by the MSEC WG.

There are a couple of problems with the above text.

First, AH [RFC4302] is listed as a MUST. This is old/obsolete. The
newer versions of the IPsec architecture have changed this to a
MAY. ESP now includes integrity protection, so one can achieve
authentication via ESP and NULL encryption. Thus, the node
requirements document will change AH to a MAY. (This should not be a
controversial change.)

The real issue though is as follows:

The key managment recommendation is only a SHOULD, yet doesn't
actually recommend one particular protocol. That said, the only
available key management protocol is effectively IKE. Thus, the Node
Requirements recommendation is a SHOULD for IKE (and IKEv2 in
particular).

But, RFC 4301 (the Security Architecture) is listed as a MUST. If one
looks at 4301 closely, it effectively mandates IKEv2 (see
http://www.ietf.org/mail-archive/web/ipsec/current/msg06259.html). That
is, the IPv6 Node Requirements RFC says SHOULD for IKEv2, yet
indirectly also says MUST for IKEv2. Talk about wanting it both
ways...

Some more thoughts.

1) Mandating IPsec (just ESP) without also supporting a key management
   protocol has rather limited applicability. For many years, the IPv6
   WG has insisted on IPsec being a MUST (for strong security), but in
   the absence of key management, that requirement (IMO) rings hollow.

2) The IPv6 WG has in the past been hesitant to mandate IKE for all
   hosts. This was viewed as a difficult requirement for some
   devices. Although there are more implementations of IKE today, I
   suspect there would still be hesitation to mandate IKE on all
   nodes.

3) We've gained a lot of experience with security and security
   protocols over the last decade.  If there is one overarching
   lesson, it's that security isn't easy, and it's not just about
   protocols. It's also about key distribution, certificates,
   operational practices, etc.

   Moreover, it is now recognized that with security, there is no
   one-size-fits-all panacea. We have a plethora of security
   technologies (ssh, ssl, tls, IPsec, etc.) and some really are more
   appropriate for some applications than others.  So IPsec is not
   going to turn out to be the single "holy grail" security
   technology. It has its place, and I expect we'll see a lot more
   usage of it over the next decade, but it is not likely to displace
   all other approaches. And for some classes of devices and
   applications, other security protocols will be more appropriate
   than IPsec.

4) The breadth and range of devices that support IP is simply
   staggering. Many are small, and some are so small, they really do
   have legitmate issues with supporting IKEv2. Does it make sense for
   the IETF to mandate that an iPod run IPsec and/or IKE? Sensor
   devices?  Personally, I don't think so.

   Even the current recommendation that IPsec/ESP be a MUST seems a
   bit like ivory-tower syndrome. IPsec does make sense in a lot of
   environments, but simply isn't required in all devices. And having
   the IETF say it is required hasn't forced all vendors to implement
   IPsec in their devices.

Thus, it is my recommendation that the next version of the node
requirements document make support for IPsec and IKE both SHOULDs
only, with a lot more explanatory text that makes it clear that there
are some types of devices where IPsec is not necessarily the best
choice.

Thoughts?

Proposed new text:

10.  Security

   This section describes the specification of IPsec for IPv6 nodes.

   Achieving security in practice is a complex undertaking.
   Operational procedures, protocols, key distribution mechanisms,
   certificate management approaches, etc. are all components that
   impact whether security is actually achieved in practice. More
   importantly, deficiencies or a poor fit in any one individual
   component can significantly reduce the overall effectiveness of an
   particular security approach.

   IPsec provides channel security at the Internet layer, making it
   possible to provide secure communication for communication flows
   between pairs of internet hosts. IPsec provides sufficient
   flexibility and granularity that individual TCP connections can
   (selectively) be protected, etc.

   IKEv2 is the key management protocol for IPsec. Although manual
   keying can be used with IPsec in some cases, the overall
   applicability of statically configured keys is limited. Thus, IPsec
   without IKEv2 has only limited value.

   A range of security technologies and approaches proliferate today
   (e.g., IPsec, TLS, SSL, SSH, HTTPS, etc.) No one approach has
   emerged as an ideal technology for all needs. It seems clear that
   for the foresable future, that situation will not change. Moreover,
   IPsec is not viewed as the ideal security technology for all
   approaches and is unlikely to displace the others. That is, IPsec
   is not viewed as a good choice for all security needs.

   Previously, IPv6 mandated implementation of IPsec and recommended
   the key management approach of IKE. This document updates that
   recommendation by making support of both IPsec and IKEv2 a SHOULD
   for IPv6 nodes. In particular, it is recognized that there are a
   range of device types and environments where other approaches to
   security than IPsec can be more appropriate. This is particularly
   the case for smaller specialized, single-purpose devices that
   support only very limited applications or run on constrained
   hardware. In other environments, support for IPsec and IKEv2 should
   be considered a very strong SHOULD, if not a MUST.

   
10.1.  Requirements

   Security Architecture for the Internet Protocol [RFC4301] SHOULD be
   supported by all nodes. Those nodes implementing the Security
   Archecture MUST support ESP [RFC4303] and MAY support AH
   [RFC4302]. In addition, such nodes SHOULD implement IKEv2 [RFC4306].

10.2.  Transforms and Algorithms

   The current set of mandatory-to-implement algorithms for ESP and AH
   are defined in 'Cryptographic Algorithm Implementation Requirements
   For ESP and AH' [RFC4835].  IPv6 nodes implementing IPsec MUST
   conform to the requirements in [RFC4835].

10.3.  Key Management Methods

   An implementation MUST support the manual configuration of the
   security key and SPI.  The SPI configuration is needed in order to
   delineate between multiple keys.

   Where key refresh, anti-replay features of AH and ESP, or on-demand
   creation of Security Associations (SAs) is required, IKEv2 keying
   MUST be supported.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------