[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 --------------------------------------------------------------------
- [secdir] are IPsec/IKE MUST or SHOULD implement f… Laganier, Julien