Internet Draft Tomoaki Kobayakawa Expires: April 2003 Shin Miyakawa NTT Communications October 2002 Requirements for Plug and Play IPsec for IPv6 applications Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document describes requirements about how IPsec is supplemented for IPv6 Plug and Play applications. 1. Motivation 1.1 Reasons to employ IPv6 IPv6 is the economically valid choice for peer-to-peer applications that require global IP addresses because IPv6 global addresses are abundant (IPv4 global addresses are not, especially in Asia.) Such peer-to-peer applications often require authentication and secrecy mechanisms, which are provided by IPsec. Another IPv6 advantage over IPv4 is the Plug and Play feature based on Stateless Address Auto Configuration [RFC2462] technologies, which enable IPv6 users to use IPv6 devices without configurations. This zero-configuration feature of IPv6 encourages manufacturers of embedded devices to choose IPv6 instead of IPv4 because embedded Kobayakawa, et al. [Page 1] Internet Draft PnP IPsec Requirements October 2002 devices are often difficult to configure before use. This is where the current IPsec is not optimized. The following are examples of such embedded peer-to-peer IPv6 applications: - Video camera and display connected with IP networks - On-Line games without central servers - Remote control of home appliances 1.2 Another IPv6 Employment Reasoning: IPv6 myth, "IPv6 is secured by IPsec" There is another reason for Internet users to choose IPv6. IPv6 is believed to be equipped with IPsec as default, and many users choose IPv6 because of IPsec. However, IPsec is independent from version numbers of IP, and IPv6 does not have special advantages for IPsec. We have two options to cope with this myth: (a) Educate users (b) Design supplemental architecture, which enables most communications among IPv6 devices to be encrypted by IPsec without too much configurations This document covers option (b), and we call this kind of IPsec as "Plug and Play IPsec." 2. Requirements 2.1 Credentials Credentials should not be PKI based. The reasons why we avoid employing PKI are: - Maintenance of X.509 certificates is complicated for embedded devices - Deployment of PKI, as the global infrastructure, can be the rate-determining step of deployment of IPv6 peer-to-peer applications Many IPv6 applications assume embedded devices without keyboard and display. For embedded devices, maintaining X.509 certificate, such as Certificate Update and Certificate Revocation Handling, is too heavy and often diminishes the usability. There are also obstacles to deploy globally available PKI and its arrival is not foreseeable. Because of the above reasons, credentials should be non-PKI based. 2.2 Security Policy Master security policy should be maintained outside IPsec devices and Kobayakawa, et al. [Page 2] Internet Draft PnP IPsec Requirements October 2002 should be dynamically installed when needed because some embedded devices do not have strong human interfaces to manipulate security policies. Decision whether to accept a proposal to establish SA or not should be asked of outside servers each time. However, we should not mandate the existence of this outside server because there are many situations in which such servers are not available, and IP layer authentication and Man-in-the-Middle protection are not important. 2.3 Optional authentication and zero-configuration mode (Plug and Play IPsec) As mentioned above, authentication should be an option. In this authentication-less mode, IPv6 IPsec devices can establish IPsec SAs without any pre-configuration. Devices should be able to discover whether the peer supports the same kind of IPsec without disturbing communications with legacy devices. In such zero-configuration mode, we can accept Man-in-the-Middle attack vulnerability. After the establishment of this security level of IPsec SAs, authentication, authorization, accounting, and Man-in-the-Middle prevention are added on to those SAs. We call this kind of gradual IPsec application as "Progressive IPsec." Application should be able to start communication from any phase. If an application does not care about strict security, that application does not have to wait to start communication until SA is established. If an application cares about security very much, the application should just wait until the full-range of security is provided after the last phase of SA establishment. This implicitly requires APIs that exchange SA status between the application layer and the IPsec layer. 3. Considerations 3.1 Man-in-the-Middle attack mitigation Man-in-the-Middle attack cannot be mitigated without pre- configuration (Inter-lock Protocol [Interlock] may be the solution, but it's not practical to apply to IP communications.) Assuming no pre-configuration, just Diffie-Hellman without authentication will work for some situations such as wireless LAN. 3.2 Just Diffie-Hellman before every communication Just "key-exchange-before-all-the-communication" does not work because it forces delay on all the communications regardless of this kind of IPsec supports. Key exchange should be triggered not by data packets but by some IPsec discovery procedures during data communications. This procedure should not hinder communicating with legacy devices, and also be achieved without pre-configurations in Kobayakawa, et al. [Page 3] Internet Draft PnP IPsec Requirements October 2002 order to actualize Plug and Play IPsec. 4. Conclusion In order to deploy IPv6 peer-to-peer applications and IPv6 itself, we need the Plug and Play IPsec. The features of the Plug and Play IPsec are as follows: - Configuration-less IPsec application to every IPv6 communication - Optioned full-range security features - Disuse of PKI - External security policy management The architecture could be developed using the IKE(v2) core. 5. Acknowledgements We would like to thank Barbara Fraser, Steve Deering, Margaret Wasserman, and Derek Atkins for insightful discussions. NTT-MCL security team members, Anand Desai, Satomi Okazaki, and Yiqun Lisa Yin, provided cryptographic suggestions. 6. References [Interlock] R. L. Rivest and A. Shamir, "How to expose an eavesdropper", Communications of the ACM, 27:393-395, April 1984. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [RFC2462] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Author's address Tomoaki Kobayakawa Innovative IP Architecture Center, NTT Communications Corporation Tokyo, Japan Tel: +81-3-6800-3262 Fax: +81-3-5265-2990 Email: tomoaki@nttv6.jp Kobayakawa, et al. [Page 4] Internet Draft PnP IPsec Requirements October 2002 Shin Miyakawa, Ph.D Innovative IP Architecture Center, NTT Communications Corporation Tokyo, Japan Tel: +81-3-6800-3262 Fax: +81-3-5265-2990 Email: miyakawa@nttv6.jp Kobayakawa, et al. [Page 5]