Mobile IP Working Group Hesham Soliman, Ericsson INTERNET-DRAFT Karim ElMalki, Ericsson Expires: Feruary 2001 Tomas Goldbeck-Lowe, Ericsson August, 2000 Security Association establishment for route optimisation in MIPv6 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This draft introduces a simple mechanism that allows an MN to establish a security association with a CN to enable it to send Binding Updates in a secure manner as required by MIPv6. The proposed mechanism is only inteneded for securing network signalling data (eg. BUs from MN) but not necessarily payload information. Soliman, El-Malki, Goldbeck-Lowe [Page 1] INTERNET-DRAFT SA establishment using AAAv6 August, 2000 TABLE OF CONTENTS 1. Introduction..................................................3 2. Establishing SAs..............................................3 3. Acknowledgements..............................................6 4. References....................................................6 5. Intellectual Property Statement...............................6 6. Author's Address..............................................6 Soliman, El-Malki, Goldbeck-Lowe [Page 2] INTERNET-DRAFT SA establishment using AAAv6 August, 2000 1. Introduction MIPv6 provides a powerful and flexible way of optimising a route between a MN and a CN based on an end-to-end approach. Route optimisation is required to reduce the delays in packet arrivals between a CN and a MN. Such delays may be significant, depending on the number of hops between a MN and its HA and the level of congestion in such path. Route optimisation is achieved when an MN sends a Binding Update (BU) to a CN. According to [MIPv6], BUs MUST be secured by at least an Authentication Header [AH]. Security association establishment between a MN and a CN requires that the MN has some security credentials (key) that can be trusted by the CN and a mechanism to exchange such keys. One possible key exchange mechanism is explained in [IKE]. The aim of this draft is to introduce a simple mechanism based on the AAA infrastructure that allows key generation and distribution for securing BUs between a MN and a CN. The proposed mechanism relies on the existing trust models within a AAA infrastructure, hence resulting in less messages required to exchange keys between an MN and a CN. This will reduce connection setup latencies as well as the overhead (ie. number of messages) required for security association establishment. Such enhancements are especially relevant to real time services and wireless networks where radio links have strict requirements on Bandwidth efficiency. Furthermore, since the proposed mechanism assumes an existing level of trust within the AAA infrastructure, the required protocol would be relatively simple to implement. It should be noted that the proposed mechanism is not intended to replace current key exchange mechanisms (eg. IKE). When using the proposed mechanism in this draft, the local AAA servers for both the CN and the MN will be aware of the keys exchanged between the MN and the CN. Hence this method may not necessarily be secure enough for certain applications. However, the proposed mechanism may be sufficient for securing BUs between a MN and a CN. 2. Establishing Security Associations 2.1 Initial assumptions and limitations Since no AAA protocol has been decided upon yet to authenticate an IPv6 user to the network, some assumptions are made about the services that will be provided by the AAAv6 protocol. These assumptions may be used by developers as requirements on AAAv6. Soliman, El-Malki, Goldbeck-Lowe [Page 3] INTERNET-DRAFT SA establishment using AAAv6 August, 2000 It is assumed in this memo that AAAv6 will allow the generation of an MN-AAAL security association of limited lifetime. This key may be used by the MN to communicate with AAAL in a secure mannner. It should be noted that AAAL in this context may mean AAAH if the MN happened to be at its home domain. In this memo, the communication between the MN and AAAL is not assumed to use the same protocol as the AAA-AAA servers communication protocol. This allows for some flexibility for the MN-AAA protocol choice. It is implicitly assumed in this memo that AAAH for a MN will cache the MN's location information (ie. it's AAAL) when authenticating the MN to a foreign domain. AAAL information is assumed to be transferred to AAAH while transferring the MN's security credentials to be authenticated by its AAAH. Since no method currently exists to allow route optimisation between IPv6 and IPv4 hosts. IPv6 MNs will not be able to use this method when communicating with IPv4 hosts. 2.2 Operational overview The model proposed for establishing a Security Association is illustrated below in Fig. 1. The communication between the MN and the CN is divided into two separate protocols: the IPv6 host-AAA server protocol and the AAA-AAA server protocol. Messages received from IPv6 hosts by the AAA server are translated and forwarded to the other host's AAA server. It should be noted that the model shown below need not be limited to security associations between IPv6 hosts. The same model can be used to establish security associations between IPv6 hosts and IPv6 routers, provided routers have pre-established security associations with their local domain's AAA servers. 2 +---------+ --------------------> +--------------+ |AAAH/L MN| <----------------------|AAAH/L CN | +---------+ 3 +--------------+ | /\ | /\ | /\ | | | | | | | | 2a | | | | | | 1 | | 2b| 3 | 4 | | | | | | | | | | | | \/ | \/ | \/ | +------+ +-----------+ | MN | | CN | +------+ +-----------+ A MN may request another entity, with which it has a pre-established Soliman, El-Malki, Goldbeck-Lowe [Page 4] INTERNET-DRAFT SA establishment using AAAv6 August, 2000 trust (eg. AAAL), to set up a security association between the MN and another CN for securing BU messages. The request can be sent to the AAAL which in turn relays it to AAAH for the MN. Alternatively the MN can send the request directly to AAAH-MN. The first alternative (MN- AAAL) is preferred as it would limit the use of the permanent MN-AAAH security keys, providing a more secure method of communication. This is due to minimising the use of the pre-established MN-AAAH security association. The information passed from the MN to the AAAL server (message 1 above) should contain the following: - Message authentication based on MN-AAAL Security Association. - MN's Home Address. - IPv6 address or NAI for the CN. - Security algorithms supported by the MN. - Lifetime requested for the generated association. The request is forwarded from AAAL to AAAH (in case the MN is in a foreign domain). The request MUST be secured by using the AAAL-AAAH security association. Upon reception of the request from the MN, AAAH needs to locate the AAAH-CN. The request is then translated to the appropriate server- server AAA protocol and forwarded to the AAAH-CN. This is shown as step 2 in the figure above. Upon reception of the request by the AAAH-CN, a decision is made as to whether a key is generated immediately or after consulting the CN. The decision is based on the AAA server's knowledge of the CN. For example, a CN may have a certain profile in the AAA server that allows it to make such decision based on the CN's security preferences. Otherwise the CN is consulted first as shown in Fig. 1 by sending message 2a. The message contains all the information given by the MN. The contents of the message should be validated by the CN and result in sending a reply message 2b. If the CN agrees to set up a security association it should include a supported algorithm and a lifetime value for the security association. Otherwise a rejection is sent with the appropriate error code. It should be noted that the key generated may not have the same lifetime value as the one requested by the MN. Upon reception of an acceptance from the CN, the AAAH-CN should generate the key and send it to the CN (message 3) and the AAAH-MN. The CN should reply to the AAAH-CN with an acknowledgement. It should be noted that the communication between AAAH-CN and the CN is done via AAAL while the CN is outside the AAAH-CN domain. This is to eliminate the use of the CN-AAAH pre-established security Soliman, El-Malki, Goldbeck-Lowe [Page 5] INTERNET-DRAFT SA establishment using AAAv6 August, 2000 association. AAAH-CN should have knowledge of the CN's current AAAL. This knowledge can be stored while authenticating the CN to the foreign domain. Finally, the reply is relayed by the AAAH-MN to the MN via AAAL. In the case where the MN is located in the AAAH-MN domain, the MN should send the request directly to AAAH-MN. The MN should use its MN-AAAH session key for communicating with AAAH. 3. Acknowledgements The basic concepts behind this draft were discussed between the authors, Annika Jonsson and Martin Korling. We would like to thank them for their input. 4. References [MIPv6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, February 2000. [IKE] D. Harkell and D. Carrel, _The Internet Key Exchange_, RFC 2409. [AH] S. Kent and R. Atkinson, _IP Authentication Header_, RFC 2402. 5. Intellectual Property statement see http://www.ietf.org/ietf/IPR/ERICSSON-General 6.Authors' addresses Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au Karim El Malki Ericsson Radio Systems AB Access Networks Research SE-164 80 Stockholm SWEDEN Soliman, El-Malki, Goldbeck-Lowe [Page 6] INTERNET-DRAFT SA establishment using AAAv6 August, 2000 Phone: +46 8 7573561 Fax: +46 8 7575720 E-mail: Karim.El-Malki@era.ericsson.se Tomas Goldbeck-Lowe Ericsson Radio Systems AB Networks and Systems Research SE-164 80 Stockholm SWEDEN Phone: +46 8 764 1467 Fax: +46 8 404 7020 E-mail: Tomas.Goldbeck-Lowe@era.ericsson.se Soliman, El-Malki, Goldbeck-Lowe [Page 7]