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, basavaraj.pa...@nokia.com 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" <nar...@us.ibm.com> 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 >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------