Mobile IP Working Group Hesham Soliman, Ericsson INTERNET-DRAFT Karim El Malki, Ericsson Expires: February 2002 Tomas Goldbeck-Lowe, Ericsson July, 2001 Security Association establishment for Mobile IPv6 Route Optimisation using AAA 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 describes a simple mechanism that allows a 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 makes use of the AAA infrastructure and is only intended for securing network signalling data (e.g. BU's from MN) but not traffic. It should be noted that the use of this mechanism need not be limited to MIPv6 BUs and may be utilised to allow any two nodes to setupa security asociation using the AAA infrastructure. Soliman, El-Malki, Goldbeck-Lowe [Page 1] INTERNET-DRAFT SA establishment using AAAv6 February, 2001 TABLE OF CONTENTS 1. Introduction..................................................3 2. Limitations...................................................4 3. Establishing SAs..............................................4 4. Acknowledgements..............................................6 5. References....................................................6 7. Authors' Addresses............................................7 Soliman, El Malki, Goldbeck-Lowe [Page 2] INTERNET-DRAFT SA establishment using AAAv6 February, 2001 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 in the path MN-HA-CN and the level of congestion in such path. Route optimisation is achieved when a 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 and CN have some authorisation credentials (e.g. certificates) and a mechanism to establish SAs which includes key exchange. 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 a MN and a CN than for example IKE requires. This will reduce connection setup latencies as well as the overhead (i.e. 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. In the proposed AAA model, the AAA servers/clients within one network domain share a security association, e.g. a AAA client in an attendant node have a SA with the AAA server in the same network. All traffic between these entities are authenticated using this SA. Also, AAA servers in different domains share the same type of SA as part of the roaming agreement. It should be noted that the proposed mechanism is not intended to replace key exchange mechanisms (e.g. IKE, KINK) aimed at generic SA establishment between two nodes. The mechanism described in this draft mainly addresses SA establishment for the needs of MIPv6 signalling between MN and a CN which belong to networks supporting AAA. When using the proposed mechanism in this draft, the home AAA servers will be aware of the SA between the MN and the CN. This mechanism will therefore provide sufficient security for MIPv6 BUs only under the assumption that the owners of the AAA home servers (i.e. the operators which the MN and CN trust and have a subscription to) have no interest in disrupting the communication of their customers. Finally, by using this mechanism, the authorisation issues for accepting a BU from a MN will be resolved. Soliman, El Malki, Goldbeck-Lowe [Page 3] INTERNET-DRAFT SA establishment using AAAv6 February, 2001 2. Limitations The mechanism proposed in this draft only applies when both the MN and the CN are connected to the AAA infrastructure. This means that hosts that do not rely on the AAA infrastructure, can not use this method. The CN may be a fixed or mobilie host,router, or server. 3. Establishing Security Associations 3.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. 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. Also, direct communication between the AAA and the MN is an option but it is NOT mandated, even though the figures may indicate that. A node in between, often referred to as attendant, should be allowed. If the attendant is present, it will handle the translation from the IPv6 host protocol to the AAA server protocol. 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. The key request message will be defined as extensions to both the host-AAA server protocol and the AAA-AAA server protocol. That will allow all servers to identify the request as a key request for binding updates between the specific MN and CN. 3.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 attendant or local 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 they have pre-established security associations with their respective AAAH servers. Soliman, El Malki, Goldbeck-Lowe [Page 4] INTERNET-DRAFT SA establishment using AAAv6 February, 2001 2 +---------+ --------------------> +--------------+ |AAAH/L MN| <----------------------|AAAH/L CN | +---------+ 5 +--------------+ | /\ | /\ | /\ | | | | | | | | 2a| | | | 6 | | 1 | |2b |3 |4 | | | | | | | | | | | | \/ | \/ | \/ | +------+ +-----------+ | MN | | CN | +------+ +-----------+ Figure 1. Basic model A MN may request another entity, with which it has a pre-established trust (i.e. AAAH-MN), 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 information passed from the MN to the AAAL/AAAH server (message 1 above) should contain the following: - Message authentication based on MN-AAAH Security Association. - MN's Home Address and NAI. - IPv6 address or NAI for the CN. - Security algorithms supported by the MN. - Lifetime requested for the generated security association. Users must be forbidden from using, for the SA establishment procedure, home IP addresses which cannot be authenticated/authorised by the AAAH. Therefore the AAAH MUST reject an SA establishment request (message 1) which contains a MN home address/NAI and does not provide the appropriate message authentication based on the MN-AAAH shared secret. This assumes the Mobile IP model where the MN has a pre-shared secret with its home network. 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 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. Soliman, El Malki, Goldbeck-Lowe [Page 5] INTERNET-DRAFT SA establishment using AAAv6 February, 2001 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. It should be noted that the messages 2a and 2b are optional and may not be sent if the AAAH-CN has the necessary information about the MN. 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, or a positive decision taken directly by the AAAH-CN based on the CN profile, the AAAH-CN should generate the key and send it to the CN (message 3) and to the AAAH-MN. The CN should reply to the AAAH-CN with an acknowledgement. After this, the key is also sent to the AAAH-MN. It should be noted that it is possible that the communication between AAAH-CN and the CN is done via AAAL while the CN is outside the AAAH- CN domain. In this case AAAH-CN should have knowledge of the CN's current AAAL. This knowledge can be stored while authenticating the CN to the foreign domain and is within the scope of the AAAv6 work. Finally, the reply is relayed by the AAAH-MN to the MN via AAAL or directly. 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. 4. 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. The authors would also like to thank Pekka Nikander (Ericsson) for his valuable feedback. 5. 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. Soliman, El Malki, Goldbeck-Lowe [Page 6] INTERNET-DRAFT SA establishment using AAAv6 February, 2001 [AH] S. Kent and R. Atkinson, "IP Authentication Header", RFC 2402. 7. 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 LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 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]