(12) United States Patent
`Cheng et al.
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006418130Bl
`US 6,418,130 B1
`Jul. 9, 2002
`
`(10) Patent No.:
`(45) Date of Patent:
`
`(54) REUSE OF SECURITY ASSOCIATIONS FOR
`IMPROVING HAND-OVER PERFORMANCE
`
`(75)
`
`Inventors: Yi Cheng, Solna; Lars Bjiirup,
`Stockholm; Martin Jakob Rinman,
`Taby; Karl Dan Gustav Jerrestam,
`Johanneshov, all of (SE)
`
`(73) Assignee: Telefonaktiebolaget L M Ericsson
`(publ), Stockholm (SE)
`
`wo
`
`5,243,653 A
`5,293,423 A
`5,444,766 A *
`5,546,464 A
`5,778,075 A *
`6,253,321 B1 *
`
`9/1993 Malek et a!.
`3/1994 Dahlin eta!.
`8/1995 Farwell et a!. .............. 455/437
`8/1996 Raith et a!.
`7/1998 Haartsen ..................... 375/138
`6/2001 Nikander et a!.
`........... 713/160
`
`FOREIGN PATENT DOCUMENTS
`wo 0139538
`* 5/2001
`
`H04Q/7/38
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 09/234,512
`
`(22) Filed:
`
`Jan.21, 1999
`
`Related U.S. Application Data
`(60) Provisional application No. 60/115,349, filed on Jan. 8,
`1999.
`
`Int. Cl? ................................................. H04M 1/66
`(51)
`(52) U.S. Cl. ....................... 370/331; 455/411; 455/410;
`370/328; 370/338; 380/247
`(58) Field of Search ................................. 370/328, 338,
`370/331; 455/410, 411; 380/247
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,081,679 A
`
`1!1992 Dent
`
`* cited by examiner
`
`Primary Examiner---Hassan Kizou
`Assistant Examiner-Tim Spafford
`(74) Attorney, Agent, or Firm-Burns, Doane, Swecker &
`Mathis, L.L.P.
`
`(57)
`
`ABSTRACT
`
`In a radio telecommunication system, the performance of a
`mobile unit can be significantly improved during a hand(cid:173)
`over procedure by reusing existing security associations that
`correspond to the mobile unit. By reusing existing security
`associations, a mobile unit can begin secure communica(cid:173)
`tions immediately following the hand-over. Otherwise, and
`in accordance with conventional practice, the mobile unit
`will have to undertake the time consuming task of renego(cid:173)
`tiating the required security associations, before it can begin
`transmitting and receiving secure communications.
`
`35 Claims, 5 Drawing Sheets
`
`101
`<
`
`MU
`
`(f)
`
`- - - - - - - - - - - ---
`
`105
`<
`
`suk
`
`(2)
`
`( 3)
`
`suk+1
`
`\
`110
`
`Ex. 1015
`Apple v. MPH Techs. Oy
`IPR2019-00820
`
`0001
`
`

`

`U.S. Patent
`
`Jul. 9, 2002
`
`Sheet 1 of 5
`
`US 6,418,130 B1
`
`101
`<
`
`MU
`
`( 1 )
`
`FIG. 1
`
`- - - -- - - - - -----
`
`105
`_(
`
`suk
`
`(2)
`
`(3)
`lr
`
`suk+1
`
`~
`110
`
`0002
`
`

`

`U.S. Patent
`U.S. Patent
`
`Jul. 9, 2002
`Jul. 9, 2002
`
`Sheet 2 of 5
`Sheet 2 of 5
`
`US 6,418,130 B1
`US 6,418,130 B1
`
`201
`
`-1'0 -
`
`2 ...
`
`(\J
`
`-v -
`
`1
`
`-
`
`+
`.JI:
`::::>
`(/)
`
`'
`
`C\J
`(.9 -
`LL..
`
`-(\J -
`
`.JI:
`
`::::>
`en
`
`4
`
`I
`I
`I
`I
`I
`I
`I
`I
`
`::::>
`~
`
`I()
`0
`~~
`(\J
`
`205
`
`-0 ~
`
`(\J
`
`a)
`qi
`~
`
`(/)
`(D
`0
`
`-
`-
`-
`
`0003
`
`0003
`
`

`

`U.S. Patent
`U.S. Patent
`
`Jul. 9, 2002
`Jul. 9, 2002
`
`Sheet 3 of 5
`Sheet 3 of 5
`
`US 6,418,130 B1
`US 6,418,130 B1
`
`JWIL3SSINVSdWXVSI
`SOl
`
`SsAdy
`
`
`
`AJ»NOISSSS978y|
`
`
`
`“WIYSLVIONIAQM
`
`>-...J
`W<(
`~-a::
`zw Oti
`~~
`w<!>
`(/)z
`u-w>-
`~~ -
`
`u
`Q)
`u
`
`0 ---,
`Oll
`-+
`
`.X
`::>
`(/)
`
`::>
`::E
`
`w
`~
`I-w
`u. -_J
`
`<(
`(/)
`a_
`~
`~
`<(
`(/) -
`
`U)
`..._.
`0
`1'0
`
`SO
`
`U)
`
`0 -~
`
`::>
`(/)
`
`f"()
`.
`(!) -
`lL
`
`z
`0 -(/)
`(/)
`W(f)
`en>-
`a._W
`~~
`~
`<(
`
`
`
`NOISSSSdWxVS!I
`
`(/) -
`
`'
`
`' ' ' ' ' ' '
`' ' ' ' ' ...
`
`I
`
`/
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`1/
`
`-(\J -
`
`0004
`
`0004
`
`
`

`

`U.S. Patent
`
`Jul. 9, 2002
`
`Sheet 4 of 5
`
`US 6,418,130 B1
`
`_J
`
`-a..
`en w
`........ :r:
`<:( -en
`0 u g
`0
`0:: a..
`rf> -
`
`(.)
`IJJ
`
`<:( en -
`' ' ' ' '
`' ' '
`' ' ' ' ' ' '
`
`w
`~
`I-
`w
`LL
`_J
`
`<:( en
`
`(.)
`IJJ
`
`cf> -
`
`en
`w
`I-
`:::> m
`0::
`I-
`I-
`<:(
`
`<:( en
`a..
`~
`~
`
`10
`
`---
`0 v
`
`10
`0
`~
`
`.X
`
`:::> en
`
`~ .
`(.!) -LL
`
`w
`Cl
`en
`0
`~ >-w
`_J ~
`0 u
`z
`0
`-
`0
`en
`I-
`en
`0
`0:: w
`en
`a..
`frl
`IJJ cf'
`en a..
`-
`-
`
`(.)
`
`u
`CD u
`
`0:: w
`m
`~
`:::> z
`w
`u z
`w
`:::>
`0 w en
`
`/
`
`I
`
`I
`
`I
`
`/
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`-C\1 -
`
`0 -\
`-+ .X
`
`:::)
`en
`
`:::>
`~
`
`0005
`
`

`

`US 6,418,130 B1
`
`-<t
`(J) -<(
`(I)
`::.:::
`0 z
`-v
`w
`-
`
`L{)
`.
`(.9
`lL
`
`-<t
`(J) -<(
`(I)
`::.:::
`0 z
`LLJ
`" II
`
`::)
`:IE
`0
`
`(J) m
`0
`
`-+ .¥
`
`::)
`(J)
`
`U.S. Patent
`
`Jul. 9, 2002
`
`Sheet 5 of 5
`
`-0
`
`Q) ._ ._
`0
`0
`m
`c
`~
`:J:
`(J)
`<t
`:J:
`
`::)
`:E
`
`0 --rt) -
`
`(I)
`
`:IE
`
`-~ .. -<t
`(J) -<(
`.. ~ u
`.. z -<(
`LLJ .. ::)
`(J) -<(
`0 --m c
`(I)
`::.:::
`u z
`:J: --
`
`LLJ
`~
`.. :J:
`:::>
`(J)
`:IE
`<(
`0
`
`~
`::)
`en
`
`-
`
`0006
`
`

`

`US 6,418,130 Bl
`
`1
`REUSE OF SECURITY ASSOCIATIONS FOR
`IMPROVING HAND-OVER PERFORMANCE
`
`This application claims priority under 35 U.S.C. §§119
`and/or 365 to U.S. Provisional Application No. 60/115,349
`filed in the United States on Jan. 8, 1999; the entire content
`of which is hereby incorporated by reference.
`
`5
`
`2
`LAN and mobile IP applications where the mobile unit is
`frequently undergoing hand-over from one SU to another
`and where the MU has limited computational power. Under
`such conditions, overall system performance will be excep-
`tionally low since a significant amount of time must be spent
`renegotiating SAs rather than communicating.
`
`SUMMARY OF THE INVENTION
`
`FIELD OF THE INVENTION
`
`The present invention involves wireless telecommunica(cid:173)
`tion systems and/or networks, such as wireless local are a
`networks (LANs) and Mobile Internet Protocol (IP) systems.
`More particularly, the present invention involves the reuse of
`security associations when a mobile unit or mobile terminal
`undergoes handover from one stationary unit in the network
`to another.
`
`BACKGROUND
`
`With the rapid development of wireless and mobile com(cid:173)
`munication technologies, communication security issues,
`such as user authentication, traffic privacy and message
`integrity have become important concerns. In response, a
`number of Internet Engineering Task Force (IETF) security
`protocol standards, such as the Internet Key Exchange (IKE) 25
`protocol, the Internet Security Association and Key Man(cid:173)
`agement Protocol (ISAKMP), and the Internet Protocol
`Security (IP sEc), are now employed in various wireless
`LAN and Mobile IP environments.
`The IKE protocol was designed to provide a mechanism 30
`for two or more communicating parties, such as a mobile
`unit (MU) and a network stationary unit (SU), to negotiate
`various security services and security associations. A secu(cid:173)
`rity service is a method or means for providing protection for
`the communication between the two or more parties,
`whereas, a security association (SA) is a relationship
`between the two or more communicating parties which
`defines how the parties will execute the agreed upon security
`services. A security association is actually defined by a set
`of attributes, such as an authentication algorithm, an authen(cid:173)
`tication key, an encryption algorithm, an encryption key, and
`a SA lifetime, which represents the period of time during
`which the corresponding SA is valid. As one skilled in the
`art will appreciate, the SAs must be negotiated and in place
`before the two or more parties can begin secure communi- 45
`cations the procedure for negotiating security services and
`SAs in accordance with the IKE protocol is accomplished in
`two phases. In a first phase (i.e., phase 1), the communicat(cid:173)
`ing parties negotiate the ISAKMP SA The ISAKMP SA is
`defined by a set of basic security attributes which provide 50
`protection for subsequent ISAKMP exchanges. In a second
`phase (i.e., phase 2), and under the protection of the
`ISAKMP SA, the communicating parties negotiate the IP sEc
`SAs associated with the IP sEc authentication header (AH)
`protocol and/or the IP sEc encapsulating security payload 55
`(ESP) protocol. The IP sEc protocols provide security ser(cid:173)
`vices for communications at the IP layer. As is known in the
`art, a specific IP sEcSA is uniquely defined by a security
`parameter index (SPI), a destination IP address, and an IP sEc
`protocol (i.e., AH or ESP).
`Because the SAs (i.e., the ISAKMP SA and the IP sEc
`SAs) are bound to the negotiating parties, the SAs are
`renegotiated whenever a mobile unit moves from one access
`point to another in a wireless LAN environment, or from one
`foreign agent to another in a mobile IP context. However, the 65
`IKE negotiation process is computationally intensive, par(cid:173)
`ticularly phase 1. This is especially troublesome in wireless
`
`It is an object of the present invention to provide a
`10 technique which improves the performance of a mobile unit
`(MU) in a wireless LAN or mobile IP environment, particu(cid:173)
`larly during hand-over. The present invention accomplishes
`this by reusing rather then renegotiating the security asso(cid:173)
`ciations (SAs) corresponding to the MU once the MU is
`15 handed-over. By reusing the SAs, less time is spent nego(cid:173)
`tiating SAs. Consequently, a MU can begin secure commu(cid:173)
`nications almost immediately upon being handed-over from
`one SU to a another SU.
`Accordingly, it is an objective of the present invention to
`20 provide a more efficient way to utilize SAs during hand-
`over.
`It is another objective of the present invention to reduce
`and/or minimize the latency period between the time a MU
`is handed-over to a stationary unit and the time the MU can
`begin secure communications with that stationary unit.
`It is yet another objective of the present invention to
`generally improve the performance of a MU through seam(cid:173)
`less hand-over.
`It is still another objective of the present invention to
`maintain a required level of performance without sacrificing
`communication security.
`In accordance with one embodiment of the present
`invention, the above-identified and other objectives are
`35 achieved through a method and/or an apparatus for accom(cid:173)
`plishing hand-over of a mobile unit from a first stationary
`unit to a second stationary unit. The method involves
`disconnecting the mobile unit from the first stationary unit,
`and thereafter, connecting the mobile unit to the second
`40 stationary unit. The method also involves reusing an existing
`security association to support the connection between the
`mobile unit and the second stationary unit, wherein the
`existing security association was previously used to support
`the connection between the mobile unit and the first station-
`ary unit.
`In accordance with another embodiment of the present
`invention, the above-identified and other objectives are
`achieved with a method and/or an apparatus for accomplish(cid:173)
`ing hand-over of a mobile unit from a first stationary unit to
`a second stationary unit. More specifically, the method
`involves disconnecting the mobile unit from the first sta-
`tionary unit, and thereafter, connecting the mobile unit to the
`second stationary unit. The method then involves reusing an
`existing security association to support the connection
`between the mobile unit and the second stationary unit,
`wherein the existing security association was previously
`used to ensure secure communications for a connection
`between the mobile unit and a third stationary unit, and
`wherein the third stationary unit and the second stationary
`60 unit are associated with a first administrative domain that
`employs a common security policy.
`In accordance with still another embodiment of the
`present invention, the above-identified and other objectives
`are achieved with a method for reusing security associations
`to facilitate hand-over of a mobile unit between stationary
`units that are associated with a common administrative
`domain, wherein all of the stationary units associated with
`
`0007
`
`

`

`US 6,418,130 Bl
`
`3
`the common administrative domain are subject to the same
`security policy. The method involves negotiating a first
`security association for a connection between the mobile
`unit and a first stationary unit associated with the common
`administrative domain. The mobile unit is then disconnected 5
`from the first stationary unit, and thereafter, connected to a
`second stationary unit associated with the common admin(cid:173)
`istrative domain. A first set of security association attributes,
`corresponding to the first security association, is then trans(cid:173)
`ferred from the first stationary unit to the second stationary 10
`unit. The first security association can then be employed to
`ensure secure communications for the connection between
`the mobile unit and the second stationary unit.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The objects and advantages of the invention will be
`understood by reading the following detailed description in
`conjunction with the drawings in which:
`FIG. 1 illustrates a first exemplary embodiment of the
`present invention;
`FIG. 2 illustrates a second exemplary embodiment of the
`present invention;
`FIG. 3 illustrates a first exemplary set of security asso(cid:173)
`ciation attributes being transferred in accordance with the
`present invention;
`FIG. 4 illustrates a second set of security association
`attributes being transferred in accordance with the present
`invention; and
`FIG. 5 illustrates the transfer of security association
`attribute information, in accordance with the present
`invention, using encryption and authentication techniques.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`For a better understanding of the invention, the following
`detailed description refers to the accompanying drawings,
`wherein preferred exemplary embodiments of the present
`invention are illustrated and described. In addition, the
`reference numbers used to identify key elements of the
`invention in the drawings are consistent throughout this
`description.
`The present invention involves a technique which
`improves the performance of a mobile unit or mobile
`terminal (herein referred to as a "MU") in a radio telecom(cid:173)
`munication system, particularly during hand-over, wherein
`the MU becomes disconnected from a first stationary unit
`(herein referred to as "SUkk") and connected to another
`stationary unit (herein referred to as "SU k+z") and wherein
`SU k and SU k+l belong to a common administrative network
`domain that is under the control of a common security
`policy. The present invention accomplishes this by reusing
`one or more previously established security associations to
`support the newly formed connection between the MU and
`SU k+l" By reusing these previously established security
`associations, the MU and SU k+l need not go through the
`time consuming task of renegotiating the security associa(cid:173)
`tions (herein referred to as "SA"s) each time the MU
`changes it's point of connection (e.g., undergoes hand-over)
`within the administrative domain. The present invention is
`of particularly importance where the communicating entities
`(e.g., the MU and SUk+1 ) exhibit low to medium level
`computational power, and where the MU is especially
`mobile and frequently undergoing hand-over.
`In accordance with the present invention, each of a
`number of stationary units (SUs) associated with the same
`
`4
`administrative domain, and thus under the control of a
`common security policy, are managed in an identical manner
`with respect to the SAs that are employed to protect the
`communication between the MU and the various SUs.
`Accordingly, the set of SAs that are established between the
`MU and any one of the various SUs belonging to that
`administrative domain can be reused by any one of the other
`SUs associated with that administrative domain, if and when
`the MU is handed-over to one of these other SUs. As
`previously stated, reuse of the previously established SAs
`will improve the performance of the MU during hand-over,
`without sacrificing communication security. However,
`depending upon the extent to which MU performance
`improvement is desired, two exemplary embodiments of the
`15 present invention are described herein below.
`In accordance with a first exemplary embodiment of the
`present invention, herein referred to as the partial SA reuse
`embodiment, a previously established Internet Security
`Association and Key Management Protocol (ISAKMP) SA
`20 is reused each time the MU is handed-over to another SU
`(i.e., SUk+1 ) in the administrative domain. More specifically,
`when the MU establishes a connection with a SU in the
`administrative domain for the first time, the Internet Key
`Exchange (IKE) phase 1 negotiation, which is used for
`25 establishing the ISAKMP SA, and the IKE phase 2
`negotiation, which is used for establishing the IP sEc SAs,
`are carried out in accordance with the various standards set
`forth by the Internet Engineering Task Force (IETF).
`However, as the mobile unit moves about, and is handed-
`30 over to another SU (i.e., SUk+l) associated with the same
`administrative domain, the previously established ISAKMP
`SA is reused by the MU and SUk+1 . Nevertheless, the MU
`and SU k+l still must conduct an IKE phase 2 negotiation;
`that is, the MU and SU k+Z must renegotiate the IP sEc SAs.
`35 Because the IKE phase 1 SA negotiation process is far more
`time consuming relative to the IKE phase 2 negotiation
`process, the reuse of the ISAKMP SA greatly improves the
`performance of the MU during hand-over.
`In accordance with a second exemplary embodiment of
`40 the present invention, herein referred to as the full SA reuse
`embodiment, the previously established ISAKMP SA and
`the previously established IP sEc SAs are reused each time
`the MU undergoes hand-over from one SU (i.e., SUk) to
`another su (i.e., suk+l) in the administrative domain. As
`45 stated above, when a MU connects with a SU in the
`administrative domain for the first time, the ISAKMP SA
`and the IP sEc SAs are established in accordance with the
`IKE phase 1 and the IKE phase 2 negotiation processes
`respectively. However, unlike the partial SA reuse embodi-
`50 ment described above, subsequent hand-overs result in the
`reuse of both the previously established ISAKMP SA and
`the previously established IP sEc SAs. Thus, the entire IKE
`SA negotiation process, including phase 1 and phase 2, is
`avoided. Therefore, the MU and SUk+l can begin commu-
`55 nicating with each other almost immediately after the
`ISAKMP SA and the IP sEc SAs are transferred from SU k to
`SUk+l· Consequently, the hand-over procedure is accom(cid:173)
`plished in a seamless or near seamless fashion.
`In general, the full SA reuse embodiment provides greater
`60 MU performance enhancement during hand-over than does
`the partial SA reuse embodiment. That is because the MU
`and SU k+l need not renegotiate any SAs. Why then might a
`network administrator opt to implement the partial SA reuse
`embodiment over the full SA reuse embodiment? One
`65 reason might be that the network administrator does not
`want the various SUs associated with an administrative
`domain to share the same session keys (i.e., encryption and
`
`0008
`
`

`

`US 6,418,130 Bl
`
`5
`
`5
`authentication keys) as specified by the IP sEc SAs. If, for
`example, all the SUs associated with the administrative
`domain share the same session keys and just one of the SUs
`is compromised, an attacker can probably compromise com(cid:173)
`munications between the MU and any of the SUs associated
`with the administrative domain.
`As stated previously, a specific IP sEc SA is uniquely
`identified by a security parameter index (SPI), in combina(cid:173)
`tion with a destination IP address, and a particular security
`protocol (e.g., the authentication header protocol or the
`encapsulating security payload protocol). As such, a com(cid:173)
`mon IP address is needed for all SUs in the administrative
`domain, in order to reuse an IP sEc SA. In accordance with
`the full SA reuse embodiment, this common IP address may
`be assigned to each SU as an alias IP address. However,
`under certain circumstances, a network administrator may
`not want to assign a common IP address to each SU. If this
`is the case, the network administrator is likely to opt the
`partial SA reuse embodiment rather than the full SA reuse
`embodiment.
`When a MU is handed-over from one SU (e.g. SUk) to
`another SU (e.g. SUk+1 ), the SA attributes corresponding to
`the ISAKMP SA and the SA attributes corresponding to the
`IP sEc SAs, depending upon whether the partial SA reuse
`embodiment or the full SA reuse embodiment is being
`employed, must be transferred from SU k to SU k+l· This
`transfer of SA attributes from SUk to SUk+l may be accom(cid:173)
`plished in accordance with any one of a number of exem(cid:173)
`plary techniques.
`FIG. 1 illustrates one such technique herein referred to as
`the direct transfer technique. According to the direct transfer
`technique, a MU 101 undergoes a hand-over from SUk 105
`to suk+l 110, as illustrated by the directional arrow marked
`"1". Next, SUk+l 110 contacts SUk 105 by sending a SA
`request message, as illustrated by the directional arrow
`marked "2". The SA request message specifically requests
`those SAs associated with the MU 101. Accordingly, the SA
`request message must contain an identifier code for the MU
`101. SUk 105 then replies to the SA request message by
`sending the appropriate SA attributes to SU k+l 110, as
`illustrated by the directional arrow marked "3".
`In addition to the procedural steps described above, the
`direct transfer technique illustrated in FIG. 1, might also
`involve the step of verifying that SU k belongs to the same 45
`administrative domain as SU k+l" To accomplish this, each
`SU associated with the administrative domain might main(cid:173)
`tain a list containing all IP addresses associated with the
`administrative domain. suk+lcan then perform the required
`verification by simply checking to see if the IP address
`associated with SU k is on the list. Alternatively, if admin(cid:173)
`istrative domain corresponds with an IP network or subnet,
`suk+l can simply compare the network identification por(cid:173)
`tion of SUk's IP address with the network identification
`portion of it's own IP address. If they match, SUk+l has
`verified that SU k, in fact, belongs to the same administrative
`domain. If SU k+l determines that SU k does not belong to the
`same administrative domain, then the MU and SU k+l may be
`required to renegotiate the ISAKMP SA and the IP sEc SAs,
`unless the attributes associated with the ISAKMP SA and the
`IP sEc SAs were stored, for example, in a database, as
`illustrated in FIG. 2, during a previous connection between
`the MU and any one of the SUs associated with the admin(cid:173)
`istrative domain to which SU k+l belongs.
`FIG. 2 illustrates an alternative technique for transferring
`the appropriate SA attributes. This alternative technique is
`herein referred to as the intermediate storage technique. The
`
`6
`intermediate storage technique may be preferable where the
`network configuration makes it difficult to identify SUk, or
`when direct communication between SU k and SU k+l is
`difficult or undesirable. In accordance with this alternative
`technique, as shown in FIG. 2, a MU 201 undergoes a
`hand-over from SU k 205 to SU k+l 210, as illustrated by the
`directional arrow marked "1". Prior to, simultaneous to, or
`if necessary, subsequent to the hand-over, SU k transfers the
`appropriate SAs associated with the MU 201 to a database
`10 (DES) 215, as indicated by the directional arrow marked
`"2". SUk+l 210 then sends a SA request message to the DES
`215, as illustrated by the directional arrow marked "3". As
`in the direct transfer technique, the SA request message
`contains an identifier code that specifically identifies the MU
`15 201. Thus, the DES 215 can reply to the SA request message
`by sending the appropriate SAs, associated with the MU
`201, to SU k+l 210, as illustrated by the directional arrow
`marked "4".
`As one skilled in the art will readily appropriate, the SAs
`20 contain sensitive information (e.g., session keys).
`Accordingly, the SA information that is transferred from
`SU k to SU k+l' using the direct transfer or the intermediate
`storage technique, should be protected. Therefore, encryp(cid:173)
`tion and authentication mechanisms might be employed to
`25 ensure confidentiality and authenticity for this information.
`FIG. 3 illustrates, more specifically, the SA attributes that
`might be transferred from SUk to SUk+l' if the partial SA
`reuse embodiment is employed. As illustrated, SU k 105,
`upon receiving a SA request message from SUk+1 110, as
`30 indicated by the directional arrow marked "2", sends a reply
`message 305 to SU k+l 110, wherein the reply message 305
`contains the information necessary to define the following
`ISAKMP SA attributes: the ISAKMP SA lifetime; the
`ISAKMP session keys, including the ISAKMP session key
`35 for authentication and the ISAKMP session key for encryp(cid:173)
`tion; keying material, which is required for deriving the
`IP sEc session keys; the last IKE phase 1 CEC (i.e., cipher
`block chaining) output block for generating an initialization
`vector which, in turn, is needed for the encryption of the first
`40 IKE phase 2 message. Although FIG. 3 indicates that the SA
`attributes are being transferred in accordance with the direct
`transfer technique described above, it will be readily appar(cid:173)
`ent to one skilled in the art that the intermediate storage
`technique may be employed in the alternative.
`FIG. 4 illustrates the SA attributes that might be trans-
`ferred from SUk 105 to SUk+l 110, in addition to the SA
`attributes identified in FIG. 3, if the full SA reuse embodi(cid:173)
`ment is employed. As illustrated in FIG. 4, SUk 105, upon
`receiving a SA request message from SUk+l 110, as indi-
`50 cated by the directional arrow marked "2" sends a reply
`message 405 to SU k+l 110, wherein the reply message 405
`contains the information necessary to define the ISAKMP
`SA attributes identified above in FIG. 3, and the information
`necessary to define the following IP sEc SA attributes: the
`55 IP sEc SA lifetime; the IP sEc protocols being used, that is,
`the authentication header and/or encapsulating security pay(cid:173)
`load protocols; the IP sEc protocol mode, that is, the trans(cid:173)
`port mode or the tunnel mode; the security parameter
`index( es ); the IP sEc session keys, including the session keys
`60 for authentication and encryption, as well as their respective
`algorithms; the last CEC output block prior to hand-over,
`which is used as the initialization vector for encryption of
`the first IP packet subsequent to hand-over; and the value of
`the sequence number, in accordance with the authentication
`65 header protocol or the encapsulating security payload
`protocol, just prior to hand-over, as this value plus 1 will be
`the initial value of the sequence number after hand-over for
`
`0009
`
`

`

`US 6,418,130 Bl
`
`7
`anti-relay checking purposes. As was the case in FIG. 3, the
`transfer of SA attributes in FIG. 4 is accomplished in
`accordance with the direct transfer technique described
`above. However, it will be understood that the SA attributes
`may be transferred in accordance with the intermediate
`storage technique, also described above.
`As stated previously, the first time a MU connects to any
`SU in a given administrative domain, an IKE phase 1
`negotiation and an IKE phase 2 negotiation must be
`accomplished, thereby establishing the ISAKMP SA and the 10
`IP sEc SAs respectively. However, in accordance with
`another aspect of the present invention, the SA attributes
`associated with the ISAKMP SA and the IP sEc SAs may be
`stored for a period of time, for example, a period of time
`equivalent to the ISAKMP SA lifetime and the IP sEc SA 15
`lifetime respectively. The SA attributes might be stored in a
`database, such as the database 215 illustrated in FIG. 2. By
`storing the SA attributes, the MU might avoid having to
`renegotiate the ISAKMP SA and the IP sEc SAs if the MU
`becomes disassociated with the administrative domain, for 20
`example, by being handed-over to a SU which is not
`associated with the administrative domain, and then the MU
`becomes reassociated with the administrative domain, for
`example, by being handed back-over to a SU associated with
`the administrative domain, before the aforementioned period 25
`of time expires. In accordance with this aspect of the
`invention, the transfer of SA attributes to SU k+l might be
`accomplished in much the same way as the intermediate
`storage technique illustrated in FIG. 2, but for the fact that
`the MU is handed-over to a SU associated with another 30
`administrative domain during an interim period between the
`time the MU is connected to SU k and the time the MU is
`connected to SU k+l·
`FIG. 5 illustrates a procedure for transferring SA attribute
`control messages, in accordance with an exemplary embodi- 35
`ment of the present invention, using encryption and authen(cid:173)
`tication techniques to protect the SA attributes during trans(cid:173)
`fer. While the procedure illustrated in FIG. 5 involves the
`intermediate storage technique, described above with refer(cid:173)
`ence to FIG. 2, one skilled in the art will readily appreciate 40
`that a similar procedure could be applied to the direct
`transfer technique, described above with reference to FIG. 1.
`The procedure illustrated in FIG. 5 initially begins with
`the MU undergoing a hand-over procedure from the station(cid:173)
`ary unit SUk to the stationary unit SU k+l' as indicated by the 45
`directional arrow marked "1", wherein suk and suk+l are
`associated with the same administrative domain. Therefore,
`SUk and SU k+l are subject to the same security policy. Then,
`at some point during the hand-over procedure, suk transfers
`the SA attribute control message to the DES, as indicated by 50
`the directional arrow marked "2". As shown, the SA attribute
`control message contains a MU identification code (IDMu);
`the SA attributes (ENCKsA), which are encrypted using an
`encryption key KsA; a time stamp (T); and a Hash value
`(HASHKDs)· The purpose of the MU identification code 55
`(IDMu) is to identify the SA attributes (i.e., ENCKSA) as
`being associated with the MU. The purpose of the time
`stamp (T) is inform the DES as to the period of time that has
`elapsed since the SU K sent the SA control message. If a
`significant period of time has elapsed, the DES may be 60
`designed to reject the SA attribute control message to protect
`against unauthorized replay. While the MU identification
`code a (IDMu) and the time stamp (1) are not typically
`encrypted, the SA attributes are encrypted using an encryp(cid:173)
`tion key KSA, which is shared by each of the SUs associated 65
`with the administrative domain. The Hash value
`(HASHKDB) is used for authentication purposes, and it is
`
`8
`derived using an authentication key KDB and as a function
`of the MU identification code (IDMu), the SA attributes
`(ENCKSA) and the time stamp (1). The authentication key
`KDB, like the encryption key KsA, is shared by each of the
`5 SUs associated with the administrative domain. In addition,
`it is shared by the DES.
`As stated, SU k transfers the SA attribute control message,
`containing the MU identification code (IDMu), the encrypted
`SA attributes (ENCKSA), the time stamp (T), and the Hash
`value (HASHKDB), to the DES. Upon receiving the SA
`attribute control message, the DES recalculates the Hash
`value as a function of the received values for the MU
`identification code (IDMu), the SA attributes (ENCKSA), and
`the time stamp (T), and based on the authentication key KDs·
`Then DES then compares the recalculated Hash value with
`the received Hash value. If the two values are equal (i.e., if
`the two values match), the DES authenticates SUk, and
`accepts the SA attribute control message. The DES then
`stores the encrypted SA attributes (ENCsKA) along with the
`MU identification code (IDMu)·
`Further in accordance with the procedure illustrated in
`FIG. 5, SUk+l now issues a SA attribute request message to
`the DES, as indicated by the directional arrow marked "3",
`wherein the SA attribute request message contains the MU
`identification code (IDMu)· In response, the DES transfers to
`SU k+l the encrypted SA attributes (ENCKsA) that correspond
`to the MU identification code (IDMu) contained in the SA
`attribute request message. By applying the encryption key
`KsA to the SA attributes (ENCKSA), suk+l can decipher the
`encrypted SA attributes.
`The present invention has been described with reference
`to a preferred embodiment. However, it