INTERNET DRAFT J. Floroiu
Date: November 2002 FhG Fokus
Expires: May 2003
Security Framework for the Access Control of MIPv6 Mobile Nodes
<draft-floroiu-ike4mip-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."
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.
Abstract
This draft proposes a few alterations to the Internet Key Exchange
protocol (IKE) aimed at shortening the security associations and key
management signaling. The resulting "IKE-like" exchange can easily be
embedded into AAA/Mobile IP signaling, resulting in reduced
registration and handover latencies. At the same time the premises
for a secure access control and data traffic framework for the
mobile nodes are created.
Introduction
In order to operate in a secure environment (especially when radio
links are concerned) mobile nodes require a number of security
associations to be setup between themselves and other entities that
assist them during the roaming. In most cases the setup of such
security associations must take place before any other signaling
could proceed, making it a time critical operation.
The AAA infrastructures have gained wide acceptance as instruments
for handling the authentication and manage the access control of
mobile nodes to visited networks.
IKE along with a number of related protocols has been largely adopted
for setting up secure communication channels between hosts.
Floroiu [Page 1]
INTERNET DRAFT November 2002
There has been a lot of experimentation in the area of "user plane"
integration between Mobile IP and IPsec enabling the setup of "mobile
VPNs" or the authentication (and possibly encryption over the public
Internet) of Mobile IP tunnels.
This draft aims at achieving "control plane" integration between
AAA/Mobile IP and IKE by reusing as much as possible from existing
protocols. The proposed protocol is based on mechanisms defined in
IKE and related protocols [1,2,3] (many notations have been adopted
as well).
1. Terminology
Mobile Node (MN)
Mobile IP mobile node as defined in [4,5]
Attendant (Att), AAAL (subsequently denoted as AAAF), AAAH
As defined in [6]
Authentication header (AH)
As defined [7]
Encryption header (ESP)
As defined [8]
Security association (SA)
As defined in [9]
2. Assumptions
Figure 1 depicts the signaling that takes place between a MN and the
AAA infrastructure. The "router system" (as defined in [6]) has been
assimilated to Att. The AAA request/answer exchange between AAAH and
HA (not present in [6]) uses to setting up a security association
between MN and HA (at a minimum Binding Updates need to be protected
through AH).
MN Att AAAF AAAH HA
| | | | |
|-- AAA Req -->| | | |
| |-- AAA Req -->| | |
| | |-- AAA Req -->| |
| | | |-- AAA Req -->|
| | | |<-- AAA Ans --|
| | |<-- AAA Ans --|
| |<-- AAA Ans --|
|<-- AAA Ans --|
AAA Req = AAA Request
AAA Ans = AAA Answer
Figure 1: AAA Request-Answer exchange
Floroiu [Page 2]
INTERNET DRAFT November 2002
The following assumptions have been made:
- Each pair Att-AAAF, AAAF-AAAH, AAAH-HA share a long term secret key
which enables the two entities authenticate the AAA message
exchange. The way such keys are obtained is outside the scope of
this draft, and any technique may be employed for this purpose:
Diffie-Hellman certificates, message exchange over an apriori
established TLS connection or IPsec channel, manual configuration;
- MN and AAAH share a long term secret key which enables the two
entities authenticate the AAA message exchange. For MNs such keys
may be distributed on SIM cards, for instance.
3. Security requirements
Roaming mobile nodes may visit foreign domains about which they have
no previous knowledge, hence share no trust relationship with. Not
only need mobile nodes be able to establish such a relationship, but
they also need to protect themselves against possible attacks which
may be mounted by potential attackers visiting the foreign link.
The foreign domain on the other hand needs to learn the mobile node's
identity from a trusted party and ensure that no other node can pose
as an authentic one.
Therefore, the following objectives must be met:
- Elimination of potential attacks based on MAC and IP address
spoofing, by enabling MN establish an AH tunnel with Att;
- Protection of the data traffic over the MN-Att segment by mean of
an ESP tunnel. Typically this segment is a wireless link (which
makes it vulnerable to eavesdropping) and even layer II encryption
is insufficient since all other MNs which are authorized to access
the link, share the same layer II encryption key, regardless the
domain they originate from;
MN may derive a shared secret with AAAF in order to avoid contacting
AAAH each time it moves to a new Att within the same visited domain,
enabling AAAF act as a trusted third party for the MN as long as the
current authentication session hasn't expired. The way the AAA
control messages exchanged between MN and the new Att are
authenticated, is AAA specific, and it can be assimilated neither to
a ISAKMP SA nor to a AH SA. A shared secret deriving from the
SKEYID_d key negotiated by MN and AAAF (during phase 1) may however
be appropriate for this purpose.
Relevant to the interaction with the home agent, MN must at least
establish an AH connection since at a minimum it must be able to
protect the BU. Additionally, MN may want to also ensure the
confidentiality of its data traffic, in which case an ESP tunnel must
also be negotiated.
Establishing security relationships with correspondent nodes may be
achieved in a similar way. However setting up route optimization may
be considered less time critical, therefore a MN may use reverse
tunneling via HA until a standard IKE exchange with the CN completes.
This draft does not address this case in detail.
Floroiu [Page 3]
INTERNET DRAFT November 2002
To conclude the discussion, figure 2 indicates the SAs a MN needs to
establish in order to ensure a secure framework for access control
and data traffic.
MN Attendant AAAF AAAH HA
| | | | |
|<-- AH/ESP -->| | | |
|<------ Local Auth Key ------>| | |
|<--------------------------- AH/ESP --------------------->|
Figure 2: SA protecting the MN's access control and data traffic
The three sets of SAs can be established by performing three
instances of the exchange described in the next section. The payloads
can be merged into one jumbo control message so that the overall
propagation delay is one MN-HA round trip (if, however, fragmentation
is avoided).
4. The protocol
4.1. Notations
A{K}(M) Authentication of message M with symmetric key K. M is
typically the preceding payload and therefore abbreviated
by "..."
KE Diffie-Hellman public key
N Nonces
SA Security association payload
sa Security association "pre-proposal" specifiying the
protocols to be negotiated during phase 2. It is
transmitted unprotected (unencrypted) and consists of a
sequence of proposal payloads indicating only the
protocols (not the transforms), the SPI field may be set
to 0
IDc Client identity
1, 2 When follows KE, N, SA or sa indicates that the
corresponding parameter is relevant to ISAKMP phase 1,
respectively 2
_i, _r When used as suffixes indicate that the parameter is
produced by the initiator, respectively by the responder
Floroiu [Page 4]
INTERNET DRAFT November 2002
HDR ISAKMP header
* When follows HDR indicates ISAKMP encryption
[ ] Indicates optional fields
4.2. Message exchange
The message exchange that takes place between peers, as depicted in
figure 1, may be decomposed into a number of elementary exchanges
like in figure 3, where I (initiator) is the MN, R (responder) is
either Att, AAAF or HA and T (trusted third party) is AAAH.
I R T
| | |
| --- Message_1 --> | --- Message_2 --> |
| <-- Message_4 --- | <-- Message_3 --- |
| | |
Figure 3: Request/Answer exchange between I, R and T
It was already assumed that I and T, as well as R and T share trust
relationships that enable the two pairs authenticate the message
exchange, typically by using pre-shared keys (SK_it and SK_rt,
respectively).
Message_X (X = 1..4) denote the control messages exchanged by I, R
and T which are typically composed of a sequence of AVPs containing
control information relevant to the AAA and Mobile IP protocols. The
set of existing AVPs is extended with a number of AVPs that
encapsulate control information relevant to the SA and key management
(a set of IKE payloads). The exchange of these latter AVPs is
depicted in figure 4, each newly introduced AVP being delimited with
angle brackets. All other AVPs are omitted for simplicity, therefore
Msg_X should be considered as being embedded into Message_X (X =
1..4).
Msg_1: I->R <HDR, SA1_i, KE1_i, N1_i, sa2_i>, A{SK_it}(...)
Msg_2: R->T <HDR, SA1_i, KE1_i, N1_i, sa2_i>, A{SK_it}(...),
<HDR, SA1_r, KE1_r, N1_r>, A{SK_rt}(...)
Msg_3: T->R <HDR, SA1_r, KE1_r, N1_r>, A{SK_it}(...),
<HDR, SA1_i, KE1_i, N1_i, sa2_i>, A{SK_rt}(...)
Msg_4: R->I <HDR, SA1_r, KE1_r, N1_r>, A{SK_it}(...),
<HDR*, HASH(2), SA2_r, N2_r, [KE2_r], IDc_r, IDc_i>
Msg_5: I->R <HDR*, HASH(1), SA2_i, N2_i, [KE2_i], IDc_r, IDc_i>
Figure 4: The exchange
Floroiu [Page 5]
INTERNET DRAFT November 2002
The authentication of the messages corresponding to the IKE phase 1
is delegated to the AAA infrastructure and it is done in a way
consistent with the AAA specification, for instance by appending an
AVP containing a HMAC computed over the protected fields.
Msg_1 contains the IKE header, the phase 1 SA proposal, initiator's
nonce, public DH key and a phase 2 SA "pre-proposal". The phase 2 SA
"pre-proposal" cannot be encrypted at this stage, the contained
information is therefore limited to enumerating the protocols the MN
wants to negotiate in phase 2. The message is packed into one AVP
which is authenticated using the pre-shared key known to I and T.
Msg_2 is built by appending to Msg_1 a new AVP containing the
response of R. This latter AVP is authenticated using the pre-shared
key known to R and T. At this moment R does not know yet whether the
IKE message received from I is authentic or not, therefore the
computations it performs must be reduced to a minimum. R does not
need to generate a fresh public DH key, since the same key may be
reused for a limited time or number of connections, and R does not
compute yet the shared secret. However R needs to generate a coockie
and a nonce N1_r.
Msg_3 contains the same 2 AVPs as Msg_2, but T reverses them, so that
both I and R can authenticate the message sent by the peer.
As R receives Msg_3, the authenticity of the IKE message sent by I is
proven, therefore R consumes it. Then R computes the SKEYID suite of
shared keys and constructs the (authenticated and encrypted) phase 2
message. The SA2_r proposal is compiled according to the MN's sa2_i
"pre-proposal". Similar to IKE, PFS may be afforded by providing a
new DH public key.
Peer identifiers ID_cr and ID_ci are needed in order to indicate the
peer's IP addresses. This is particulary important because for the
IPsec connection with Att, MN uses the care-of address as the source
address, while in home agent's SPD the peer's source address is the
MN's home address. If the home address and the care-of address are
dynamically allocated, they are assumed to be available at the moment
Msg_4 is sent.
Finally, I responds with Msg_5 indicating the accepted AH/ESP SA
proposals. Upon reception of Msg_5, R derives the shared keys,
installs the SAs and sets up the AH/ESP tunnels. I may immediately
proceed with sending AH/ESP traffic.
As soon as the initial SAs are in place, throughout the AAA
authentication session's lifetime, and while connected through the
same Att, the phase 2 SAs may be renegotiated periodically directly
between I and R using a message exchange like the one below:
Floroiu [Page 6]
INTERNET DRAFT November 2002
Msg_3: I->R HDR*, HASH, sa2_i
Msg_4: R->I HDR*, HASH(2), SA2_r, N2_r, [KE2_r], ID_cr, ID_ci
Msg_5: I->R HDR*, HASH(1), SA2_i, N2_i, [KE2_i]
SKEYID_a and SKEYID_e negotiated during phase 1 are used to
authenticate and encrypt the exchange, which follows the
same pattern as in figure 4.
When moving to a new Att, MN and the new Att use AAAF as a trust
party and follow the exchange described in figure 4.
5. Security Considerations
The protocol aims at enhancing the security of MNs visiting foreign
domains and relies on the security properties and trust model of the IKE
protocol and AAA infrastructure.
References
[1] Harkins, D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409,
November 1998
[2] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol (ISAKMP)",
RFC 2408, November 1998
[3] Piper, D., "The Internet IP Security Domain Of Interpretation for
ISAKMP", RFC 2407, November 1998
[4] Perkins, C., Editor, "IP Mobility Support for IPv4", RFC 3344,
August 2002
[5] Johnson, D., Perkins, C. Arkko, J. "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-19.txt, work in progress
[6] Perkins, C., Eklund, T., "AAA for IPv6 Network Access",
draft-perkins-aaav6-06.txt, work in progress
[7] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998
[8] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)"
RFC 2406, November 1998
[9] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol", RFC2401, November 1998
Floroiu [Page 7]
INTERNET DRAFT November 2002
Author's Address
Questions about this memo can also be directed to:
John Floroiu
FhG Fokus
31 Kaiserin-Augusta-Allee
10589 Berlin, Germany
Phone: +49 (0)30 3463 7144
Email: floroiu@fokus.fhg.de
Floroiu [Page 8]