Handover%20and%20Authentication%20in%20WLANs

1
Handover and Authentication in WLANs

• Ping Yu

2
Outline

• Introduction
• Motivations and Objectives
• Key Issues for Achieving Seamless Mobility
• Handover Process Overview
• Fast Authentication Methods for Intra-ESS
  handovers
• Issues and Solutions in inter-ESS handovers
• Fast Authentication Methods in Inter-domain
  Handovers
• Conclusions
• References

3
Introduction

• WLANs (Wireless LANs), have gained a lot of
  popularity.
• due to its low cost and relatively high bandwidth
  capabilities.
• These networks typically offer access to the
  Internet and/or corporate networks for delivery
  of application level services
• such as multimedia.
• IEEE 802.11 networks consist of access points
  that can be interconnected to form a single
  so-called hotspot.
• In principle, such a hotspot has only limited
  geographical coverage.

4
Network Architecture and Mobility Scenarios 4
5
Categories of Handover Scenarios

• Handover Scenario 1 intra-ESS mobility
• MN changes APs connected to the same ARs
  interface
• Transparent to the routing at the IP layer (L3)
• Appears simply as link layer (L2) mobility
• Handover Scenario 2 inter-ESS mobility
• MN mobility changes the ARs network interface to
  the MN
• Serving AR remains the same but routing changes
  internal to the AR
• In principle, the MN can even keep its
  IP-address.
• Handover Scenario 3 inter-ESS mobility
• MN changes ARs inside the same domain
• This requires higher hierarchical routers to deal
  with the locally changed IP-address of the MN
• Handover Scenario 4 inter-domain mobility
• MN moves to a new network domain
• Involves the assignment of a completely new IP
  address to the MN
• Invocation of L3 mobility management

6
Motivation

• Problem
• having continuous access to multimedia services
  while moving from one hotspot to another?
• Motivation
• Handover (re-establishing connectivity to a new
  access point) takes considerable time (up to 1
  second) in WLANs.
• This is not acceptable for a number of
  applications, such as VoIP.

7
Improvements in Handover Delays

• Therefore, a number of efforts have resulted in
  improvements in handover delays.
• IAPP (Inter-Access Point Protocol), as
  standardized in IEEE Std 802.11f
• enables (fast) link layer re-association at a new
  access point in the same hotspot.
• On the network layer, IETF Seamoby group
• defines different protocols to reduce network
  discovery and reconfiguration delays.

8
Issues for achieving seamless mobility

• Three key issues of current standards and
  protocols for achieving seamless mobility across
  network domains
• Authentication delay
• network discovery
• inter-layer communication

9
Trust Model

• To design a security solution for intra- and
  inter-domain handover or evaluate its
  performance, the trust relations between the
  entities involved must be identified.
• All trust requirements ask, for security
  mechanisms to mutually authenticate the network
  and the MN at access time before granting network
  access 5.
• Three entities involved in the authentication
  process
• MN, AP, and AS (Authentication Server).
• IEEE 802.11i task group has made assumptions with
  respect to trust during mobility
• A MN trust the (home) AS and the AP with which
  the MN is associated
• The MN does not trust all non-associated APs in
  the first instance.

10
Trust Model

• Trust relationships between different entities
  when a MN associates with an AP, denotes as old
  AP (oAP), then roams to new AP (nAP).
• Trust relationships before and during a handover
  4

• the solid lines represent explicit mutual trust
  relationships
• the dotted lines trust represent implicit
  relationships.
• Implicit relationships must be created
  dynamically to gain access to the network media.
• To create the implicit trust relationships and
  dependent of the mobility scenario, one may make
  use of the trust relationships between oAP and
  nAP, between oAR and nAR, and between oAS and nAS
  (designated by TL2, TL3 and TR, respectively).

11
How these implicit trust relationships are
established?

• Before a Handover (right after when the MN gets
  powered on within a domain)
• the implicit L2 trust relationship between the AP
  and the MN is transitive and derived from the
  fact that
• the MN and the AS mutually trust each other
  (possibly via the home AS of the MN)
• the AS and AP trust each other (usually via a
  shared, preconfigured secret).
• In order to establish that trust relationship,
  the AP and MN must convince each other that they
  are who they claim to be, and must mutually
  derive the necessary encryption and
  authentication keys based upon keying material
  from the mutually trusted AS. For this, IEEE Std
  802.11i is devised.
• An implicit L3 trust relationship must be
  established between the MN and the AR.
• Here we have a similar situation as in
  establishing the L2 trust relation, where two
  entities share a trust relationship with a third
  entity the AP generally trusts the AR and the MN
  trusts the AP (on the basis of the L2 implicit
  MN-AP trust), therefore, the MN may trust the AR.
  

• During a Handover (when a MN roams from the cell
  area of oAP to nAP)
• new implicit L2 and L3 trust relationships must
  be established between the MN and nAP and the MN
  and nAR.
• The trust relationships are between oAP and nAP,
  between oAR and nAP, and between oAS and nAS
• When both oAP and nAP belong to the same hotspot,
  the IEEE Std 802.11f 17 foresees a means of
  creating a secure communication channel TL2
  between them.
• During an intra-domain handover and when the AR
  changes, the Seamoby WG mechanisms 184
  exploit the trusted channel TL3 between oAR and
  nAR.
• During an inter-domain handover when the AS
  changes, a roaming agreement TR between two
  domains establishes a trust relationship between
  oAS and nAS.
• Note that IEEE 802.11f and Seamoby are not
  directly applicable for the inter-domain
  scenario. Moreover, note that IEEE 802.11f only
  cover intra-ESS handovers.
• Establishing an implicit L3 trust relationship
  between the MN and nAR
• the nAP trusts the nAR and the MN trusts the nAP.
  
• Alternatively, an implicit L3 trust relationship
  between MN and nAR can be created transitively
  from the previous trust relationship between
  MN-oAR and the TL3 between oAR and nAR, if
  applicable.

12
Handover Process Overview

• L2 Handover in IEEE 802.11 WLANs
• L3 Handover

13
L2 Handover in IEEE 802.11 WLANs

• L2 handover
• When a MN moves out of the coverage area of a
  oAP, the MN reassociates with a neighbour nAP,
  where both APs belong to the same ESS. The
  mechanism or sequence of messages between a MN
  and the APs that results in a transfer of
  physical layer connectivity and state information
  from oAP to nAP.
• Handover delay or latency
• During a L2 handover, the MN is mostly unable to
  exchange the data traffic via its oAP and nAP.
  This interval of no communication is often
  referred to as handover
• The MN initiates the so-called re-association
  service to carry out the IEEE 802.11 handover
  process.
• The handover process can be split into three
  phases
• detection, search, and execution
• For the L2 handover process, the description here
  is based on the IEEE 802.11 standard and its
  security protocol suite of IEEE 802.11i.

14
Handover process based on IEEE 802.11/802.11f 4
15
Handover process based on IEEE 802.11/802.11f

• Detection Phase
• In this phase the MN detects the need for a
  handover.
• The need for handover can be based on
• detecting lack of connectivity via the current AP
  (in other words, detecting the loss of expected
  traffic)
• detecting a more suitable (e.g., cheaper)
  connection.
• Search Phase
• The search phase includes a set of so-called
  scans performed bythe MN to find the APs in
  range. The standard mandates scanning of all IEEE
  802.11 channels.
• On each channel, the IEEE 802.11 standard
  specifies two scanning modes active and passive.
  
• In passive scanning, MNs listen to each channel
  for the beacon frames announcing the services of
  a particular AP. This may induce long delays
  (more than 1 second).
• In active scanning, MNs broadcast a probe-request
  management frame in each channel and wait for
  probe responses generated by APs, as illustrated
  by messages 1 and 2 in Figure 3. Active scanning
  is usually faster, but consumes more power and
  bandwidth.
• Execution Phase
• A two-step process authentication and
  re-association.
• Typically the nAP needs to authenticate the MN
  before the re-association succeeds.
• The IEEE Std 802.11 specified two authentication
  algorithms open system and shared key. These
  have been superseded by IEEE 802.11i that deals
  with security flaws of the open system and shared
  key solutions. The messages of IEEE 802.11i are
  exchanged after the re-association process.

16
Security Issues

• A malicious MN should not be able to re-associate
  (hijack session) or disassociate (perform DoS
  attack) on behalf of the associated MN.
• Thus, the authenticity of the re-association or
  disassociation requests must be guaranteed.
• As the MN drives the re-association process, it
  is important that the MN proves its relationship
  with the oAP to the nAP.
• Ciphers such as TKIP or CCMP can be used to
  authenticate, integrity and replay protect and
  encrypt the re-association/disassociation frames.
  Alternatively, a so-called Authenticator
  Information Element (IE) can be added to the
  frames.

17
Solution

• Because wireless networks are by definition
  vulnerable to snooping and possible intrusion by
  3rd parties, mutual authentication and trust
  needs to be established (and reestablished when
  roaming) between APs and the MN.
• For that purpose, IEEE 802.11i prescribes the use
  of EAP/IEEE 802.1X mechanisms.
• When operating IEEE 802.1X, a Master Key (MK,
  also called AAA-key in the IEE 802.11i draft) and
  a Pairwise MK (PMK) are generated via the
  exchange between the MN and AS.
• The simplest method is EAP-MD5 challenge, which
  only authenticates the MN to the AS.
• More advanced methods, e.g., EAP-TLS, EAP-TTLS,
  EAP-SIM (protocol to enable WLAN authentication
  using any GSM phone SIM smart card), provide
  for mutual authentication of the MN and AS
• The MK is obtained from the MN-AS authentication
  during the EAP-exchange.
• The PMK may be generated from the MK (by using
  the first 32 octets of the MK 7 6), or it may
  be generated by some other means (e.g. randomly
  chosen by the AS) and protected in transport from
  the AS to the MN using material derived from the
  MK.
• Note that these methods will not authenticate the
  AP to the MN. When the PMK is generated, the AS
  pushes it securely to the AP via RADIUS
  transport. Delivery of the PMK to the AP is
  delivering the decision that the IEEE 802.1X
  authentication process was successful and is an
  indication that the IEEE 802.1X/EAP process is
  completed.

18
IEEE 802.11i operational phases 4

• the AP and the MN use the PMK to derive, bind and
  verify a fresh Pairwise Transient Key (PTK).
• This is done via the so-called 4-way handshake.
• The 4-way handshake proves the liveness of both
  peers, demonstrates that there is no
  man-in-the-middle, and synchronizes pair-wise key
  use.
• The AP uses portions of the PTK to securely
  distribute a Group Transient Key (GTK) to all
  associated APs.
• A 2-way handshake is used for this purpose. The
  GTK is used to secure broadcast messages to the
  APs.
• Either TKIP or CCMP can be used to provide for
  data protection.

19
L3 Handover

• If an IP subnet change occurs during a handover
  from oAP to nAP, then an IP level, i.e., L3,
  handover will take place. This may result in a
  change of AR from oAR to nAR. The actions carried
  out during an IP level handover can be grouped
  into three phases of movement detection, MN
  configuration and path redirection.
• Movement detection phase
• a change of IP subnet is detected.
• When the MN establishes (or wants to establish)
  L2 connectivity to a nAP, this phase determine
  whether the nAP belongs to a new IP subnet.
• Configuration phase
• When the nAP belongs to a new IP subnet, the MN
  must obtain subnet specific parameters such as
  the new IP address, referred to as Care of
  Address (CoA).
• This configuration enables the MN to communicate
  via the new IP subnet.
• Path redirection phase
• Includes measures to redirect the data flow to
  the acquired new CoA
• For example informing the correspondent nodes of
  the MN over the new CoA.
• The actions in these phases incur an additional
  delay on top of the L2 handover delay that should
  also be considered for seamless handovers across
  domains and WLANs.
• Solution Joint optimization of L2 and L3
  handover processes is perhaps the direction for
  achieving this objective.

20
Fast Authentication Methods for intra-ESS
handovers

• a substantial amount of latency is incurred
  during the exchange of authentication messages.
• The negative impact of in particular IEEE 801.1X
  authentication on the performance of the handover
  process has been recognized

• Relevant L2 solutions to reduce authentication
  latency for intra-ESS handovers
• Proactive Key Distribution
• Pre-authentication
• Predictive Authentication
• L2 Context Transfer Using IAPP

21
Proactive Key Distribution 2

• Intends to reduce the latency of authentication
  phase by pre-distributing key materials one hop
  ahead of a MN for EAP-TLS authentication.
• For each access, a Neighbour Graph captures
  dynamically the set of neighbour APs. Assume a MN
  is associated with the oAP and as a result of the
  MN-AS authentication an old PMK is shared
  between the MN and oAP.
• The following message sequence is prescribed for
  pro-active key distribution
• (1) The AS constructs the new PMK from the old
  PMK, MAC address of the MN and of the nAP, and
  sends it to the nAP (this step is repeated for
  all APs in the Neighbour Graph of the oAP, which
  is known at the AS)
• (2) When the MN roams to the nAP the MN derives
  the new PMK the same way as the AS did
• (3) MN and nAP derive a new PTK via key
  agreement, e.g., via the 4-way handshake and a
  new GTK.
• Advantages
• The authentication latency, attributed to the
  process described in the previous section, is
  reduced from an average of 1.1 sec to 25 msec
  with pro-active key distribution and Neighbour
  Graph 20.
• It also eliminates problems with sharing key
  material amongst multiple APs.
• Disadvantages
• its heavy burden on the AS server
• its requirement for new RADIUS messages

22
Pre-authentication

• IEEE 802.11i defines pre-authentication for
  roaming users. Pre-authentication can be useful
  as a performance enhancement, as the L2 execution
  phase will not include the protocol overhead of a
  full re-authentication when it is used.
• Pre-authentication relies on IEEE 802.1X.
• A MN can initiate pre-authentication whenever it
  has an association established with an oAP.
• To effect pre-authentication, the MN sends an
  IEEE 802.1X EAPOL-Start message as a data frame
  to the BSSID of a targeted nAP (within its
  present ESS) via the oAP with which it is
  associated currently.
• The targeted nAP then may initiate IEEE 802.1X
  authentication to the MN.
• The distributed system will be configured to
  forward this message to the AP with which the MN
  is associated.
• The preauthentication exchange ends when, after
  deriving the new PMK, the nAP sends the first
  message of the 4-way handshake.
• When pre-authentication is used, the MN and nAP
  must cache the new PMK that has been derived
  during the IEEE 802.1X pre-session.
• Advantages
• the authentication phase becomes independent of
  roaming
• the MN may authenticate to multiple candidate
  nAPs at the same time.
• Disadvantages
• introduces new opportunities for DoS attacks
• requires fat APs and MNs
• might unnecessarily burden the AS server (unless
  new PMK caching is used).
• not suitable for roaming scenarios 3 and 4

23
Predictive Authentication 1

• Use a modified IEEE 802.1X key distribution
  model. It supports one to many authentications,
  instead of the one to one MN-AS message delivery
  of IEEE 802.1X.
• The MN sends an authentication request to the AS,
  and the AS sends multiple authentication
  responses to all APs within a certain Frequent
  Handoff Region (FHR).
• This FHR is a set of adjacent APs and is
  determined by the APs locations and users
  movement patterns.
• The trust model is similar to that of pro-active
  key distribution and has the same benefits and
  disadvantages.
• Advantages
• The introduction of the FHR theoretically allows
  for inter-domain roaming
• Disadvantages
• the implementation of a FHR over multiple domains
  may cost a lot of effort.

24
L2 Context Transfer Using IAPP

• IAPP MOVE operation enables transferring a MNs
  context information from the oAP to nAP securely.
• uses IPsec to establish a secure channel between
  the nAP and oAP, i.e., the TL2 trust
  relationship.
• How to use IAPP context transfer features for
  fast authentication in reactive and proactive
  operation modes?
• Reactive Mode
• The context exchanged in IAPP MOVE operation may
  include security credentials whereby the implicit
  trust relationship between MN and nAP can be
  built on top of the implicit MN-oAP trust
  relationship and TL2.
• When a trust relationship between the MN and oAP
  was established, both MN and oAP share a common
  secret (e.g., the old PMK).
• The context transfer of IAPP should not enable
  nAPs to obtain the keys used for encrypting
  traffic on the oAP, because otherwise a rogue nAP
  can decrypt traffic previously captured on the
  oAP.
• Solutions
• e.g., the oAP transfers to the nAP a transfer key
  derived via a one-way function from the old key
• alternatively, the oAp derives a new key that
  does not depend on the old key.

• Proactive Caching 3
• For interactive, or high quality, real-time
  applications the performance of the context
  transfer within the IAPP MOVE protocol sequence
  is not sufficient.
• Solution
• IAPP CACHE protocol sequence to actually move the
  state to a set of nAPs, i.e. neighbouring APs,
  before the MN tries to re-associate at one of
  those nAPs. The set of neighbouring APs relative
  to an AP is called the Neighbour Graph.
• When a MN re-associates with a nAP, the nAP looks
  up its cache for the context entry of the MN.
• If the context exists and is not expired (a cache
  hit), then the nAP sends a re-associates response
  message to the MN.
• Otherwise (a cache miss), the nAP invokes the
  IAPP MOVE protocol sequence.
• Advantages
• eliminate the time needed to transfer the context
  information by the MOVE protocol sequence (after
  a reassociate request).
• Ref. 21 reports an order of magnitude
  improvement (from 15.37 msec to 1.69 msec) for
  performing the re-associate process

25
Issues in Inter-ESS Handovers

• the scope of IAPP protocol realizing the TL2in
  WLANs is limited to a single ESS and it cannot be
  applied to inter-ESS or inter domain handovers
  (i.e., scenarios 2, 3 and 4).
• Three main Issues in order to use IAPP between
  the APs of different ESSs and/or different
  domains,
• reverse address mapping to map the MAC address
  of oAPs to their IP addresses
• MNs should obtain the MAC addresses of candidate
  nAPs, while the communication between APs in IAPP
  is mainly IP based.
• IP address translation to map between private IP
  addresses of APs and routable IP addresses
• the IP addresses of APs will likely be private in
  IPv4 settings
• trust and the security issues between APs
• a known requirement for any context transfer
  process

26
Solutions to inter-ESS handovers

• Scenarios to transfer L2 context between APs in
  inter-ESS handovers, using IAPP and Seamoby
  protocols 4.
• Direct L2 Context Transfer
• Encapsulating L2 Context in L3 Context

27
Direct L2 Context Transfer

• a simple scheme to directly transfer L2 context
  between APs in inter-ESS handovers.
• With a re-associate request message the MN
  presents the MAC address of the oAP to the nAP.
• To activate the context transfer feature of IAPP,
  the nAP should know the IP address of the oAP.
  This reverse address mapping problem can be
  resolved by, for example, using a roaming server.
  This is similar to the RADIUS server as proposed
  for intra ESS handovers by IEEE Std 802.11f.
• The emergence of the address translation issue to
  transfer L2 context between APs of different ESSs
  depends on the network architecture. We consider
  two scenarios APs have private or public
  addresses.
• in the case of IPv4, the APs are likely assigned
  private IP addresses. The private IP addresses
  are hidden to the Internet and therefore a
  Network Address Translation (NAT) is used to
  convert private IP addresses to public IP
  addresses and vice versa.
• With advent of IPv6 the range of available IP
  addresses will enormously increase and therefore
  it is feasible to provide every AP with a public
  IP address. There is also an alternative IEEE
  802.11 deployment scenario where each AP is
  integrated with exactly one AR, the AP/AR has a
  public IP address. When both nAP and oAP poses
  public IP addresses, the issue of address
  translation vanishes by definition.

28
Encapsulating L2 Context in L3 Context

• The scheme embeds a L2 IAPP context in a L3
  context and transfers the result using the CTP
  (Context Transfer Protocol).
• The CTP is being defined by the Seamoby Working
  Group of IETF to transfer context information
  from a oAR to a nAR.
• The reverse address mapping issue
• the MAC addresses of candidate nAPs are mapped to
  the IP addresses of the corresponding nARs.
• resolves the address translation issue
• by exploiting the IP addresses of ARs

29
A scheme transferring L2 context within L3
context 4

• The scheme is for handover scenario 3, where an
  intra-domain handover occurs.
• MN sends a re-associate request to the nAP that
  includes the oAP MAC address and the MN MAC
  address. The nAP relays the IAPP MOVE-notify
  message to the nAR
• nAR maps the oAP MAC address into the oAR IP
  address, using the inverse address translation
  scheme as provisioned by Seamoby for the
  Candidate Access Router Discovery (CARD) protocol
  4, and nAR sends the move-notify message
  embedded in a L3 Context Transfer Request (CTR)
  message of the CTP to the oAR
• oAR checks an authorization token (issued by the
  MN) for L3 context transfer and delivers the
  MOVE-notify part of the L3 context to the oAP
• oAP checks whether there is a valid record of the
  MNs association and sends a MOVE-response
  message containing the L2 context of the MN to
  the oAR
• oAR embeds MOVEresponse message in a Context
  Transfer Data (CTD) message of CTP and sends it
  over to the nAR which extracts the L2
  MOVEresponse message from the L3 context and
  sends it to the nAP
• nAP examines the status of the MOVE-response and
  if it is successful, it initiates an ADD-notify
  (see the description below) on the new ESS and
  sends a reassociate reply message to the MN
• MN goes on with L3 configurations and path
  redirection to the new subnet (e.g., by acquiring
  a new CoA and doing the Mobile IP registration)
  and sends a Context Transfer Activate Request
  (CTAR) to the nAR.

30
Fast Authentication Methods in Inter-domain
Handovers

• Inter-domain MNs move from one visited (i.e.,
  old) domain to a new domain
• where the authentication is typically proxied
  towards the home domain of MNs.
• Of course, in practice the home domain can be the
  same as the old or the new domain.
• Inter-domain handover is not only a technical
  issue. A lot of business and trust aspects play a
  role.
• Assumption
• An intention between the two domains, i.e., a
  roaming agreement, to have inter-AP or inter-AR
  context transfer features.

• Fast Authentication Methods in Inter-domain
  Handovers 4
• Straightforward Extension of IAPP
• Inter-domain Proactive Key Distribution
• Pre-authentication over Multiple Domains

31
Straightforward Extension of IAPP

• A simplistic approach for extending IAPP for
  inter-domain mobility
• explicitly off-line connect specific APs between
  two domains using a secure connection (typically
  via a point-to-point secure connection).
• Hence, it requires an explicit network
  architecture that must be configured by the
  operator of the network.
• use the preexisting secure link (either at the
  network or transport Layer) to exchange context
  information using similar mechanisms as IAPP.
• For L2 aspects, this means that oAP must know and
  communicate with nAP (and vice-versa). This is
  similar to the standard operation of IAPP.
• Off-line connecting APs 4

32
Inter-domain Proactive Key Distribution

• The idea is to exploit knowledge of handover
  candidates in all networks and pro-actively
  distribute new PMKs over different domains.
• It involves the AS of the home domain, because
  this server is responsible for the creation of
  the required new PMKs.
• Requirements
• pushing the identification of the oAP to the home
  AS,
• computing the set of possible nAPs close to the
  oAP of the MN at the home AS
• signalling from the home AS to the new domains
  APs.
• Inter-domain Proactive Key Distribution 4

33
Pre-authentication over Multiple APs 4

• Phases
• the MN associated at the oAP pre-authenticates at
  nAP via the oAP
• EAP authentication proceeds between
  MN-oAP-nAP-nAS proxy-home AS
• the resulting PMK is stored at the nAP and the
  MN
• upon re-association at the nAP, MN is
  authenticated automatically and PTK is derived
  (PMK is stored already)
• finally, IAPP context transfer may optionally
  take place between the oAP and nAP for other
  types of information.
• Drawback the configuration of the network
  becomes quite complex
• between each couple of adjacent APs a secure
  connections is needed
• every AP needs knowledge about nearest APs
• the MN itself needs information about the
  possible nAPs that it wishes to associate to
• The authentication is governed only by roaming
  agreements between the old and new domains.

34
Conclusions

• A key issue for achieving seamless handovers
  across networks and domains
• Improving authentication delay
• Fast authentication methods when roaming within
  or across IEEE 802.11 Wireless-LANs
• IAPP and Seamoby results cannot be applied out
  of the box for inter domain seamless mobility
• Extending IAPP and Seamoby protocols for
  inter-domain mobility requires enhancements to
  the security infrastructure with mechanisms for
  home ASs to push authentication context
  information to other domains
• Inter-domain context transfer requires
  interaction with the home AS for both
  authentication and accounting. If any of these
  aspects are relevant, trust relationships between
  home AS and visited AS must be available or be
  established.

35
References

• 1 S. Pack and Y. Choi, "Fast Inter-AP Handoff
  Using Predictive Authentication Scheme in a
  Public Wireless LAN," Proceedings of IEEE
  Networks Conference, 2002.
• 2 Arunesh Mishra, Min-ho Shin, William A.
  Arbaugh, Pro-active Key Distribution using
  Neighbor Graphs, IEEE Wireless Communications
  Magazine, February 2004.
• 3 A. Mishra, M. Shin, and W. Arbaugh, "Context
  caching using neighbor graphs for fast handoffs
  in a wireless network," IEEE Infocom, Mar, 2004.
• 4 M. S. Bargh, R. J. Hulsebosch, E. H. Eertink,
  A. Prasad, H. Wang, P. Schoo, Fast
  authentication methods for handovers between IEEE
  802.11 wireless LANs, Proceedings of the 2nd ACM
  international workshop on Wireless mobile
  applications and services on WLAN hotspots,
  October, 2004.
• 5 Y. Matsunaga, A.S. Merino, T. Suzuki, R.H.
  Katz, Secure authentication system for public
  WLAN roaming, Proceeding of WMASH03, Sep. 2003