I agree. Procurement agencies can always elevate IPSec/IKEv2 to
a requirement if they need to, but we should not burden every
low-end implementation with it.
Brian
On 2010-07-21 09:44, [email protected] wrote:
> Hi Thomas,
>
> I agree with your analysis and recommendation.
> I support the idea of specifying IPSec/IKEv2 as a SHOULD in the node
> requirements I-D.
>
> -Raj
>
>
> On 7/20/10 4:27 PM, "Thomas Narten" <[email protected]> wrote:
>
>> 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
>> [email protected]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
