Internet Draft Tomoaki Kobayakawa
Expires: April 2003 Shin Miyakawa
NTT Communications
October 2002
Requirements for Plug and Play IPsec for IPv6 applications
<draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt>
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]