Secure Session Key Exchange for Mobile IP Low Latency Handoffs

Document Sample
Secure Session Key Exchange for Mobile IP Low Latency Handoffs Powered By Docstoc
					Secure Session Key Exchange for Mobile IP Low
               Latency Handoffs

            Hyun Gon Kim1 , Doo Ho Choi1 , and Dae Young Kim2
                   1
                      Information Security Technology Division,
              Electronics and Telecommunications Research Institute,
                    Gajeong-dong, Yuseong-gu, Daejeon, Korea
                          {hyungon, dhchoi}@etri.re.kr
             2
               Computer Communications Lab., InfoCom Eng. Dept.,
                          Chungnam National University,
                     Gung-dong, Yuseong-gu, Daejeon, Korea
                                 dykim@cnu.ac.kr



      Abstract. Mobile IP Low Latency Handoffs[1] allow greater support for
      real-time services on a Mobile IPv4 network by minimising the period
      of time when a mobile node is unable to send or receive IP packets due
      to the delay in the Mobile IP Registration process. However, on Mobile
      IP network with AAA servers that are capable of performing Authen-
      tication, Authorization, and Accounting(AAA) services, every Regional
      Registration has to be traversed to the home network to achieve new ses-
      sion keys, that are distributed by home AAA server, for a new Mobile IP
      session. This communication delay is the time taken to re-authenticate
      the mobile node and to traverse between foreign and home network even
      if the mobile node has been previously authorized to old foreign agent.
      In order to reduce these extra time overheads, we present a method that
      performs Low Latency Handoff without requiring further involvement by
      home AAA server. The method re-uses the previously assigned session
      keys. To provide the confidentiality of session keys in the phase of key
      exchange between old FA and new FA, it uses a key sharing method with
      a trusted third party. The proposed method allows the mobile node to
      perform Low Latency Handoff with fast as well as secure operation.


1   Introduction
The Mobile IP handoff as in [2, 3] may introduce latency and packet loss that
are not desirable for delay-sensitive and real-time applications. To reduce them,
three methods[4], Pre-Registration handoff, Post-Registration handoff, and Com-
bined handoff, for Low Latency Handoffs(LLH), currently under consideration
for standardization within the IETF, are introduced and still have much concern.
This paper motivates some basic extension to LLH for AAA. The LLH supports
both normal Mobile IP model[3] in which the mobile node(MN) receives pack-
ets from a Home Agent(HA) and the Regional Registration model[9] in which
the MN receives packets from a Gateway FA(GFA). If the distance between the
visited network and the home network of the MN is large, the signaling delay
2      H. G. Kim et al.

for these registrations may be long. The latter model reduces the number of
signaling messages to the home network and the signaling delay when the MN
moves from one Foreign Agent(FA) to another, within the same visited domain.
    However, on Mobile IP network with AAA servers, every Regional Registra-
tion has to be traversed to the home network to achieve new session keys for a
new Mobile IP session. This implies that the advantage of Regional Registration
thus, fast operation performed by local network, can’t be utilized. We present
a method for reducing these built-in delay components of LLH with AAA. The
method re-uses the session keys assigned for the previous Mobile IP session. How-
ever, since the session keys can be achieved by spoofing a registration message
when key exchange occurs between old FA(oFA) and new(nFA), an attacker can
take over an established connection. To prevent these kinds of session stealing,
the confidentiality of session keys needs to be provided. For the similar purpose,
the confidentiality of session keys based on public key cryptography has already
designed for Mobile IP with AAA[7]. But, for the LLH, it is impractical due to
the long delay caused by public key cryptography operations. We also present a
secure and lightweight session key exchange method.


2   Mobile IP Low Latency Handoffs




                                                 4. (Reg)RegReq
                                                 5. (Reg)RegReply
                                1a. RtSol

                                1b. RtAdv
                  2a.       2b.
                  PrRtSol   PrRtAdv         3. (Reg)RegReq



                                      Movement



            Fig. 1. The Low Latency Handoffs with AAA infrastructure


    Basically, the LLH focuses on the Regional Registration that performs only
local registration within visited domain. The formal description of the LLH can
be found in [1]. Fig 1 shows the LLH with AAA infrastructure, specially, Pre-
Registration handoff operation. When an MN first arrives at a visited domain,
it performs a registration with its home network. After the MN is successfully
authenticated and authorized, AAAH generates Mobile IP session keys(Mobile-
                                              Secure Session Key Exchange        3

Foreign, Foreign-Home, and Mobile-Home session key) and distributes the keys
to the Mobile IP entities(MN, FA, and HA).
    The Pre-Registration handoff method allows the MN to be involved in an
anticipated IP-layer handoff. Message 1a is Router Solicitation(RtSol). Message
1b is a Router Advertisement(RtAdv). For this to occur, oFA should solicit and
cache advertisements from neighboring nFAs. Message 2a is a Proxy Router
Solicitation(PrRtSol) which solicits an advertisement from a router different
from the one receiving this message. When message 2a is received, the oFA
returns the Proxy Router Advertisement(PrRtAdv) in message 2b. The MN
performs movement detection upon receipt of either a solicited or unsolicited
Agent Advertisement and, if appropriate, it sends a Regional Registration Re-
quest ((Reg)RegReq) message in message 3 to nFA. Messages 4 and 5 complete
Regional Registration[9]. If the Registration is successful then packets for the
MN are now tunnelled from the GFA to the nFA where the MN has moved to.


3     Secure Session Key Exchange Method

Regarding local operations, the proposed method, basically, re-uses the previ-
ously assigned session keys. However, security weakness issued by key-reuse has
to be resolved. In this section, we point out a possible Mobile IP session stealing
on the LLH and propose a secure key exchange method.


3.1   Session Stealing Attack in the phase of key exchange

The lifetime of the session keys is great enough to avoid too-frequent initiation
of the AAA key distribution, since each invocation of this process is likely to
cause lengthy delays between registrations. Once the keys have been distributed
by AAAH, the oFA has two session keys thus, Mobile-Foreign and Foreign-Home
session key. If the MN moves to an nFA region, the LLH would be performed.
Since the nFA has no session keys, re-authentication is required and new session
keys should be assigned by AAAH, which leads to long signaling delay. One
solution to perform fast operations is that the existing session keys are re-used
when there is enough key lifetime remaining in the existing registration. This
can eliminate the time required for re-authentication by AAAH.
    However, in order to re-use the session keys, they have to be taken over from
oFA to nFA in a secure fashion. Especially, the Foreign-Home session key used
between oFA and HA is a random value of at least 64 bits and it is not hashed[2].
Unfortunately, if an attacker spoofs the nFA, he can achieve the keys in the phase
of key exchange between oFA and nFA, and then the current session can be de-
rived from that key. For this security weakness, the confidentiality of the session
keys must be provided in the phase of key exchange. For the similar purpose, the
solution proposed by Jacobs[8] can be viewed as a further attempt to provide the
confidentiality of the session keys based on public key cryptography. However, it
is impractical that every FA performs public key cryptography operations that
suffer from the long delay during the handoffs. It is required that a new method
4         H. G. Kim et al.

has to be provided not only for fast operations but also for secure key exchange.
These are the main objectives in this paper.

3.2     Proposed Secure Session Key Exchange Method
The method is based on a key sharing protocol with a trusted third party instead
of public key cryptography. Basically, we assume that GFA plays a trusted third
party between FA’s and so GFA and FA have security associations. The method
proposes extensions to the Mobile IP to allow the oFA and nFA to utilize secure
session key exchange. It also enables rapid handoffs since AAA transactions,
thus, excessive signaling load and delay between home and visited network are
eliminated. Some design principles and assumptions in our new method are:
    – We try to minimize the computing power requirement as well as administra-
      tion cost imposed on MN.
    – No additional message exchange other than the LLH messages should be
      required. This will maintain compatibility with the LLH.
    – It is assumed that there is a security association between GFA and FA and
      so GFA can authenticate FA.
    – To prevent session stealing attack, session keys should be encrypted and
      exchanged in a secure fashion.
      The following notations are used:
    – SM N −F A , SF A−HA , and SM N −HA : A shared Mobile IP session key
      between MN and FA, FA and HA, and MN and HA respectively.
    – KoF A−nF A : A dynamic session key between old FA and new FA that is
      calculated instantly and not stored.
    – < M > K : MAC value of message M under key K.
    – {M }K : Encryption of message M under key K.
    – KF A : A shared secret between FA and GFA.
    – R : A random number.
    – IdF A : FA’s Identity(e.g., FA’s IP address).
    – MRRQ : Mobile IP Regional Registration Request Message.
    – MRRP : Mobile IP Regional Registration Reply Message.
   The proposed scheme re-uses the previously assigned session keys, SM N −F A
and SF A−HA . To ensure the confidentiality of the session keys, we use the en-
cryption and decryption under a short-lived secret key, KoF A−nF A , between oFA
and nFA. The key is dynamically shared between them by help of the GFA. The
proposed method is based on Network-Initiated and Mobile-Initiated Handoff,
that are specified in the LLH[1].

3.3     Network-Initiated Handoff
In the network-intiated handoff, the MN receives Router Advertisement of nFA
through oFA(Proxy Router Advertisement)[3]. Fig 2 shows the flow and opera-
tions of the proposed method that is proceeds as follows :
      Prepare Proxy Router Advertisement
                                              Secure Session Key Exchange          5




   Fig. 2. The proposed session key exchange method for network-initiated handoff


  – oFA chooses a random number R.
  – oFA computes KoF A−nF A =< R, IdoF A > KoF A .
  – oFA computes E = {SM N −F A , SF A−HA }KoF A−nF A .

    Proxy Router Advertisement(PrRtAdv)

(a1) oFA→MN : P rRtAdv, R, E, IdoF A

    Mobile IP Registration Request/Reply

 (1) MN→nFA : MRRQ , R, E, IdoF A
      • nFA stores R, E.
      • nFA computes < M > KnF A where M = MRRQ , R, IdoF A , IdnF A .

 (2) nFA→GFA : MRRQ , R, IdoF A , IdnF A , < M > KnF A
      • GFA authenticates nFA validating < M > KnF A .
      • GFA computes KoF A−nF A =< R, IdoF A > KoF A .
      • GFA computes E = {KoF A−nF A }KnF A .

 (3) GFA→nFA : MRRP , E
      • nFA obtains KoF A−nF A by decrypting E .
      • nFA retrieves E and decrypts it under the key KoF A−nF A .

 (4) nFA→MN : MRRP
 6        H. G. Kim et al.




     Fig. 3. The proposed session key exchange method for mobile-initiated handoff


 3.4     Mobile-Initiated Handoff

 In the mobile-initiated handoff, MN requests Proxy Router Solicitation(PrRtSol)
 to oFA[3]. Fig 3 shows the flow and operations of the proposed method that is
 proceeds as follows :
       Router Solicitaion/Advertisement

(a1) MN→oFA : P rRtSol
      • oFA chooses a random R.
      • oFA computes KoF A−nF A =< R, oF A > KoF A .
      • oFA computes E = {SM N −F A , SF A−HA }KoF A−nF A .
(a2) oFA→nFA : RtSol, R, IdoF A , E
      • nFA stores R, IdoF A , E.
(a3) nFA→oFA : RtAdv
(a4) oFA→MN : P rRtAdv, R, IdoF A

       Mobile IP Registration Request/Reply

 (1) MN→nFA : MRRQ , R, IdoF A
      • nFA retrieves R, IdoF A and validates R.
      • nFA computes < M > KnF A where M = MRRQ , R, IdoF A , IdnF A .
                                            Secure Session Key Exchange      7

(2) nFA→GFA : MRRQ , R, IdoF A , IdnF A , < M > KnF A
     • GFA authenticates nFA validating < M > KnF A .
     • GFA computes KoF A−nF A =< R, IdoF A > KoF A .
     • GFA computes E = {KoF A−nF A }KnF A .
(3) GFA→nFA : MRRP , E
     • nFA obtains KoF A−nF A by decrypting E .
     • nFA retrieves E and decrypts it under the key KoF A−nF A .
(4) nFA→MN : MRRP


4   Security Analysis
We provide security analysis as some protection scenarios against the possible
session stealing attacks:
 – Suppose that the attacker intercepts the message of (1) in Fig 2 or the
   message of (a1) in Fig 3. Then he knows the encrypted message E, but
   he can not decrypt E since he does not know the secret key KoF A−nF A .
   Furthermore, he can not compute the secret key KoF A−nF A since he does
   not know KoF A , even if he knows R and IdoF A .
 – Suppose that the attacker intercepts the message of (3) in Fig 2 or Fig 3.
   Then he knows the encrypted message E , but he can not compute the secret
   key KoF A−nF A from E since he does not know KnF A .
 – Suppose that the attacker intercepts a valid message MRRQ , R , IdoF A ,
   IdnF A , < M > KnF A of (2) in Fig 2 from some previous successful registra-
   tion of Section 3.3 and now impersonates as the nFA. He broadcasts a router
   advertisement RtAdv. Then in the process of Section 3.3, the oFA chooses
   a new random number R and calculates KoF A−nF A =< R, IdoF A > KoF A .
   The attacker replays the message of (2) using the recorded valid message.
   Therefore, the GFA authenticates the attacker as the nFA and GFA calcu-
   lates the previous dynamic session key KoF A−nF A =< R , IdoF A > KoF A ,
   but the attacker can not obtain the Mobile IP session keys, since he can not
   decrypt E .
The proposed method provides the confidentiality of the session keys and then
it enables secure LLH. It needs more computational operations such that oFA
and nFA have to encrypt and decrypt the session keys respectively. However,
the computational cost of public key cryptography operations is much more
expensive than the proposed method. On the other hand, since the method
performs handoff locally, AAA based re-authentication is not required and this
satisfies Low Latency Handoff requirements.


5   Experimental Results
To present the comparison of public key based handoff latency and proposed
handoff latency, we are prototyping two scenarios in an experimental system.
8      H. G. Kim et al.




            - AMR : AA-Mobile-Node-Request                       3. AMR *
            - AMA : AA-Mobile-Node-Answer
                                                                 6. AMA *
            - HAR : Home-Agent-MIP-Request
            - HAA : Home-Agent-MIP-Answer                 2. AMR
                                                          7. AMA
                                                                                   4. HAR
                                                                                   5. HAA




                                             0. RtAdv
                                                         1. RegReq
                                                         8. RegReply


                                              Movement       Note : * means RSA Encryption/Decryption,
                                                                      Signing/Verifying of AVPs in the message



                       Fig. 4. Scenario 1: public key based handoff


Fig 4 shows the scenario 1 for public key based handoff. The Mobile IPv4 func-
tionalities[1, 2] and Diameter based AAA functionalities followed by the Diam-
eter base protocol[5], Diameter Mobile IPv4 application[6], and Cryptographic
Message Syntax(CMS) security protocols[7, 8] are implemented in the system.
Simulation software is running under linux Red Hat 6.2 and XEON Pentium-
III. Every Mobile IP registration with authentication is performed by HA and
AAAH. Propagation delay between two networks is ignored.




                                                                        4. (Reg)RegReq
                                                                        5. (Reg)RegReply
                                                  1a. RtSol

                                                  1b. RtAdv
                               2a.           2b.
                               PrRtSol       PrRtAdv               3. (Reg)RegReq



                                                           Movement



                             Fig. 5. Scenario 2: proposed handoff


   Fig 5 shows the scenario 2 for the proposed handoff. The Low Latency
Handoff with proposed secure session key exchange method is performed. Thus,
the registration is locally performed without AAA authentication operated by
AAAH. Fig 6 presents the simulation results based on two scenarios described
above. The local handoff ratio, the number of local registration performed to the
home registration performed, is varied. The results represent that the proposed
method’s latency is less than the public key based handoff. It is seen that the
proposed handoff only requires around 2 msec latency at handoff ratio = 0.9. At
                                                              Secure Session Key Exchange   9

the same handoff ratio, the public key based handoff requires around 64 msec
latency.




                      Latency (msec)




                                       Scenario 1: Public key based Handoff
                                       Scenario 2: Proposed Handoff




    Fig. 6. Handoff latency between the public key approach and the proposed one




6    Conclusion
In this paper, we present a method that performs Low Latency Handoff with-
out requiring further involvement by home AAA server. Compared with existing
public key based cryptography operations, the proposed method has consider-
ably lower computational cost and handoff latency. In addition, it provides the
confidentiality of the Mobile IP session keys in the phase of key exchange in a
secure fashion; therefore, the session stealing attack could be protected.

References
1. Karim El Malki, Pat R. Calhoun, Tom Hiller, James Kempf, et al.,: Low Latency
   Handoffs in Mobile IPv4. draft-ietf-Mobileip-lowlatency-handoffs-v4-04.txt (2002)
2. Charles E. Perkins: IP Mobility Support. RFC2002 (1996)
3. Charles E. Perkins: IP Mobility Support for IPv4. RFC3220 (2002)
4. Eva Gustafsson, Annika Jonsson, Charles E. Perkins: Mobile IPv4 Regional Regis-
   tration. draft-ietf-Mobileip-reg-tunnel-06.txt (2002)
5. Pat R. Calhoun: Diameter Base Protocol. draft-ietf-aaa-diameter-17.txt (2002)
6. Pat R. Calhoun, Tony Johansson, Charles E. Perkins: Diameter Mobile IPv4 Ap-
   plication. draft-ietf-aaa-diameter-mobileip-13.txt (2002)
7. Pat R. Calhoun, Stephen Farrell, William Bulley: Diameter CMS Security Applica-
   tion. draft-ietf-aaa-diameter-cms-sec-04.txt (2002)
8. S. Jacobs: Mobile IP Public Key Based Authentication. draft-jacobs-Mobileip-pki-
   auth-03.txt (2001)
9. E. Gustafsson, et al.,: Mobile IP Regional Tunnel Management. draft-ietf-Mobileip-
   reg-tunnel-06.txt (2002)

				
DOCUMENT INFO
Shared By:
Tags: mobile
Stats:
views:39
posted:10/27/2010
language:English
pages:9
Description: Most simply, mobile IP technology is to make the computer on the Internet and LAN real-time roaming without any restriction, also known as mobile computing. Professional point of explanation, the mobile IP technology is the mobile node (computer / server / network segment, etc.) to a fixed network IP address, to achieve roaming across different network segments, and to ensure that IP-based network in the roaming network permissions process does not any changes.