INTERNET-DRAFT P.Nikander Ericsson Research 24 June 2002 Trust Models for Secure IPv6 Neighbor Discovery 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and it expires December 24, 2002. Please send commetns to the author and/or to the SEND BoF mailing list. Table of Contents 1. Abstract 2. Trust Models 2.1. Corporate Intranet Model 2.2. Public Wireless Network with an Operator 2.3. Ad Hoc Network 3. References 4. Author's Addresses 5. Copyright Statement 1. Abstract This document outlines three different trust models for Secure IPv6 Neighbor Discovery (SEND). The trust models correspond to a trusted company intranet, a public network with a trusted service provider, and a public network without any trusted parties. 2. Trust Models When considering various security solutions for the IPv6 Neighbor Discovery (ND) [RFC2461], it is important to keep in mind the underlying trust and threat models. Since the threat model is represented in a separate draft [THREAT], this draft concentrates on specifying the trust models. Three different trust models are specified: 1. A model where all authenticated nodes trust each other. This model is thought to represent a situation where the nodes are under a single administration and form a closed or semi-closed group. A corporate intranet is a good example. 2. A model where there is a router trusted by the other nodes in the network. This model is thought to represent a public network run by an operator. The clients pay to the operator, have its credentials, and trust it to provide the service. The clients do not trust each other. 3. A model where the nodes do not directly trust each other at the IP layer. This model is considered suitable for e.g. ad hoc networks. 2.1. Corporate Intranet Model In a corporate intranet or other network where all nodes are under one administrative domain, the nodes may be considered reliable at the IP layer. Thus, once a node has been accepted to be a member of the network, it is assumed to behave in a trustworthy manner. Under this model, if the network is physically secured or if the link layer is cryptographically secured to the extend needed, no other protection is needed for ND. For example, a wired LAN with 802.1x access control or a WLAN with 802.11i RNS/EAP may be considered secure enough, requiring no further protection under this trust model. On the other hand, if the network is not physically secured and the link layer does not have cryptographic protection, or if the cryptographic protection is not secure enough (e.g. just 802.1x in a WLAN), the nodes in the network may be vulnerable to some or all of the threats outlined in [THREAT]. In such case some protection is desirable to secure ND. One possiblity would be to use IPsec AH with symmetric shared keys, known by all trusted nodes and by no outsiders. 2.2. Public Wireless Network with an Operator A scenario where an operator runs a public wireless (or wireline) network, e.g. a WLAN in a hotel, air port or cafe, has a different trust model. Here the nodes may be assumed to trust the operator. However, they do not usually trust each other. Typically the router (or routers) fall under one administrative domain, and each of the client nodes fall under their own administrative domain. It is assumed that under this scenario the operator authenticates all the client nodes, or at least requires authorization in the form of a payment. At the same time, the clients are able to authenticate the router and make sure that it belongs to the trusted operator. The authentication protocol allows the client nodes and the access router to create a security association. In this scenario, cryptographically securing the link layer does not necessarily block all the threats outlined in [THREAT]. Specifically, even in 802.11i with EAP the broadcast and multicast keys are shared between all nodes. Therefore some of the attacks described in [THREAT], or variants of them, may still be possible or even easy to launch. The reason for this difference from the model above is that some of the clients may be malevolent, and therefore may send false multicast and broadcast packets. Even if the underlying link layer was aware of all the nodes' link layer addresses, and could check that no source addresses were falsified, there may still be vulnerabilities. There seems to be two ways to fix this scenario. One is to enforce strong security between the clients and the access router, and make the access router aware of the next layer protocol details. That is, the router would check ICMPv6 packet contents, and filter packets that contain information which does not match the network topology. The other way is to add cryptographic protection to the ICMPv6 packets carrying ND messages. This seems to require new methods for effective key distribution. 2.3. Ad Hoc Network In an ad hoc network, or any network without a trusted operator, none of the nodes trust each other. Since there are no a priori trust relationships, the nodes cannot rely on traditional authentication. However, it is still possible to use self-identifying mechanisms, such as Cryptographically Generated Addresses [CGA]. These allow the nodes to ensure that they are talking to the same nodes at all times, and that each of the nodes indeed have generated their IP address themselves and not "stolen" someone else's address. It may also be possible to learn the identities of any routers using various kinds of heuristics, such as testing the node's ability to convery cryptographically protected traffic towards a known and trusted node somewhere in the Internet. Methods like these seem to mitigate (but not completely block) some of the attacks outlined in [THREAT]. 3. References [CGA] M. Roe, T. Aura, G. O'Shea, J. Arkko, "Authentication of Mobile IPv6 binding updates and acknowledgements, work in progress, draft-roe-mobileip-updateauth-02.txt, IETF Mobile IP WG, February 2002. [RFC2461] T. Narten, E. Nordmark, and W. Simson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December, 1998. [THREAT] J. Kempf, E. Nordmark, "Threat Analysis for IPv6 Public Multi-Access Links", work in progress, draft-kempf-ipng-netaccess-threats-01.txt, June, 2002. 4. Author's Addresses Pekka Nikander Oy L M Ericsson Ab c/o Helsinki Institute for Information Technology (HIIT) Tammasaarenkatu 3 P.O.BOX 9800 FIN-02015 HUT Finland E-mail: pekka.nikander@nomadiclab.com 5. Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.