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
<draft-soliman-mobileip-routeopt-mipv6-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 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]