Authentication of Mobile Users Refik Molva ? Didier Samfat EURECOM Institute CICA , 2229 Route des Cr ^ etes F-06560 Valbonne - FRANCE fmolva,samfatg@eurecom.fr Gene Tsudik IBM Research Laboratory Saumerstrasse 4 CH-8803 Ruschlikon - Switzerland gts@zurich.ibm.com December 27 , 1993 Abstract Internetworks of the future will allow and promote universal access . Users will be able to access the network at a multitude of access points separated by significant geographic distance and many administrative boundaries . Without a single central authority , a new set of inter-domain security mechanisms is needed to allow users to venture into remote domains while inheriting privileges from their home domain . Solutions addressing this issue must take into account a somewhat contradictory security constraint that calls for strict separation of security domains in order to avoid sharing sensitive user-related security information . In this paper , we propose a generic approach for authenticating mobile users in remote domains that satisfies the domain separation constraint . The protocols described herein can be applied in different mobile-user environments including wireless networks and mobile user services on traditional wireline networks . 1 Introduction Recent emergence of network technology which supports user mobility has prompted new security requirements and concerns . This is mainly due to the lack of physical protection mechanisms as in traditional fixed-topology , static-user networks . User mobility and universal network access certainly exasperate certain security threats such as illegal access -LRB- fraud -RRB- and eavesdropping . In addition , one new factor brought about by mobility is the ever-increasing distance that can separate network access points . Since network access points are not necessarily under the control of the same administrative authority , a new set of inter-domain mechanisms is needed in order to allow users to perform security operations in visited domains . Potential solutions must take into account a somewhat contradictory security constraint that calls for strict separation of security domains in order to avoid sharing domain-specific security information . The goal of this paper is to propose a general approach for the authentication of users in remote domains while maintaining strict separation of security domains . This paper is organized as follows . We begin in section 2 by discussing security issues specific to user mobility and identifying authentication requirements . Section 3 summarizes authentication solutions in existing mobile-user environments . Section 4 presents our solution to authentication of mobile users . Some variations on the theme are introduced in Section 5 and Section 6 concludes with the summary of the paper . ? Names appear in alphabetical order . 2 User Mobility and Its Security Implications User mobility is a feature that can be offered in different network environments . Some environments are , by definition , oriented towards mobile users . These include all types of wireless networks such as infrared and radio -LRB- cellular being the most popular . -RRB- Other environments can be adapted to support user mobility , i.e. , a wireline network can be equipped to allow universal access through offering a value-added service such as Universal Personal Telecommunication -LRB- UPT -RRB- -LSB- 15 -RSB- . Furthermore , the current trend is towards mixing wireline and wireless access within an internetwork . To this end , the rest of the paper tries to play down the distinction between wireless and wireline access in order to keep the discussion fairly general . 2.1 Establishing Temporary Residence Abroad We begin by stating the basic assumption of user mobility , that a user has but one home . A user 's home is the administrative domain where he is registered on a long-term basis . Typically , it is also the place where accounting and billing information is accumulated . In some sense , a home domain bears some responsibility for its constituent users . As a mobile user migrates throughout an internetwork , he1 periodically pops up in a new , foreign domain . A user may be simply transiting a foreign domain or planning to linger about for some time . Regardless of his intentions or the type of access -LRB- i.e. , via a cellular phone or a fixed workstation -RRB- the goal of a mobile user is to obtain some service from the network . In order to do that , he must first establish temporary residence in the foreign domain . User mobility in the network environment is not unlike mobility in the real world , where a person travelling from one country to another must often engage in some bureaucratic procedure the purpose of which is to establish temporary physical residence in the new location . In the real world the procedure of establishing a temporary residence varies one country to another . The same can be expected of network domains . At the first glance , it seems that the problem can be easily solved by requiring each mobile user to carry a universally-recognized credential , i.e. , a passport . An electronic equivalent of a passport is called an electronic certificate . There are electronic certification schemes based on public key as well as conventional cryptography . One notable example is Privacy-Enhanced Mail -LRB- PEM -RRB- -LSB- 11 , 12 , 13 -RSB- . Given a certificate of a foreign user , any domain can verify the credential and confirm the identity of that user . However , there are several issues that can not be addressed with electronic certification . ffl While a certificate 's authenticity is readily verifiable , its current status is not . In other words , since a mobile user demands service -LCB- not a free commodity -LCB- the foreign domain may need to establish that a newly-arrived , visiting user is currently in good standing . This can not be accomplished without some interaction with the user 's home domain , since only the home domain is able to comment on the user 's current standing . For example , if a user obtains service while abroad and is later billed for it , the home domain may refuse to pay since the expenditures were not authorized . ffl Some domains may desire to restrict the mobility of their constituent users ; such constraints may be very difficult to encode in a universal certificate . ffl Another problem with electronic certificates is the underlying assumption that the user has some means of carrying his certificate , e.g. , within a cellular phone , a personal communicator or a smartcard . However , in the simplest mobile-user environment -LRB- e.g. , UPT -LSB- 15 -RSB- -RRB- , a user is `` armed '' with only a password or a PIN -LCB- something that a human brain can easily retain . In summary , universal user certification is not sufficient or well-suited for establishing temporary residence in a foreign domain . In addition , the preceding discussion points to the need to contact the user 's home domain . Even if access control is not an issue and if the user 's ability to pay for services can be confirmed on-the-spot -LRB- e.g. , with electronic cash -LSB- 21 , 22 -RSB- -RRB- , the user 's home domain must be contacted if only for the reason of tracking . This is because a user is normally registered with his home domain on a long-term basis ; 1No gender implication . anyone wanting to contact a user has to consult his home domain first . Therefore , it is natural for a domain to track the whereabouts of its constituent users . 2.2 Migration Among Foreign Domains There is a slight difference between a user appearing in a foreign domain and moving between two adjacent foreign domains . While a user makes his way from one foreign domain to another , his credibility must be confirmed with every crossing of domain boundaries . In general , we can not assume that the path taken by a mobile user is continuous . That is , a user may operate in one domain and several hours later pop up in another domain thousands of miles away , e.g. , an 8-hour flight from Switzerland to the United States carries a user between two distant , non-adjacent domains . Somewhat different dynamics take place in a typical wireless environment where , instead of simply popping up , a user may wander into a new domain . The difference is best illustrated by an example : a cellular telephone subscriber engaged in a conversation crosses the domain boundary in real-time while , say , driving a car . This type of movement can be classified as continuous as opposed to discrete where a subscriber simply turns on his cellular phone far away from home . -LRB- The latter case is essentially the same as in the wireline environment . -RRB- This type of real-time inter-domain transition demands real-time hand-over of user 's state including current session activity data and authentication/authorization information . A simple case is when a user is migrating from his home domain to an adjacent one ; the hand-over can be done in a trivial manner . In a more general scenario , a user migrates from one foreign domain to another . Both domains can be very far away from home and it is not obvious how to authenticate a user in a new domain -LRB- in real-time -RRB- without incurring the overhead of contacting the home domain . 3 Existing Approaches In this section we briefly review how current mobile-user environments reconcile user mobility with authentication . 3.1 GSM Groupe Special Mobile -LRB- GSM -RRB- -LSB- 1 , 2 -RSB- is the first mobile digital cellular network architecture to provide security services such as user authentication , traffic confidentiality and key distribution . GSM subscribers -LRB- users -RRB- are traced during their intra - and inter-domain movements . Each Mobile Station -LRB- MS -RRB- informs the network of its position ; this information is used to update the Visiting Location Register -LRB- VLR -RRB- and the Home Location Register -LRB- HLR -RRB- . Furthermore , the establishment of communication is under control of the Authentication Center -LRB- AUc -RRB- which is often co-located with the local Message Switching Center -LRB- MSC -RRB- where most domain-wide policy is enforced . For each active or passive MS , real-time identification of the visited domain and authentication of both caller and called MS is performed in order to avoid fraud . Every GSM subscriber has in his MS a smartcard -LRB- SIM -RRB- containing a secret key Ki known only by the HLR . When the MS notifies the local MSC of its presence , the local VLR contacts the mobile unit 's HLR and transmits his own identity , the mobile station 's International MS Identity -LRB- IMSI -RRB- and position to the HLR . The HLR asks its local AUc for a set of triplets containing : a challenge -LRB- random number RAND -RRB- , a signed response -LRB- SRES -RRB- , and a corresponding session key -LRB- Kc -RRB- . The triplets are then forwarded back to the VLR and each triplet is used only once for the authentication of the MS. Parameters SRES and Kc are computed with proprietary algorithms A3 and A8 that implement one-way functions : ffl SRES = A3 -LRB- Ki ; RAND -RRB- ffl Kc = A8 -LRB- Ki ; RAND -RRB- HOTELVACANCY Mobile System Authentication in GSMHLRVLRMSMS Identifier - IMSIIMSI , VLRA set of -LSB- RAND , SRES , Kc -RSB- RANDSRESStored KiSRES = A3 -LRB- Ki , RAND -RRB- Kc = A5 -LRB- Ki , RAND -RRB- Figure 1 : Mobile Station authentication in GSM Subsequently , privacy between the MS and the local MSC is achieved by enciphering data with Kc . A5 is another proprietary algorithm used to encipher data , speech and signalling messages : ffl Ciphertext = A5 -LRB- Kc ; Cleartext -RRB- ffl Cleartext = A5 -LRB- Kc ; Ciphertext -RRB- Figure 1 depicts the MS authentication protocol in GSM . Message flows between HLR and VLR perform the export of the subscriber 's credentials from the home domain to the remote domain while the interaction between MS and VLR consists of challenge-based authentication of MS by VLR . The main concern with the GSM authentication approach is its reliance on the security of the internetwork that is traversed by the V LR $ HLR communication . Even if this was a reasonable assumption for the signalling networks of today 's mobile telephone systems , the same can not be guaranteed in a large or globalscale , administratively heterogeneous network environment . What is needed is a security architecture with minimal assumptions about the security of intermediate transport networks . Another point of contention with GSM is the manner of distributing user authentication information . The home domain is expected to generate on-the-fly a set of challenge/response pairs that the foreign domain is then supposed to use in successive authentication flows with the end-user . This solution is inefficient in terms of both bandwidth consumption and the overhead incurred at the home domain . In addition , since only a -LRB- presumably -RRB- small number of such challenge/response pairs is communicated , their supply can eventually be depleted and the foreign domain would have to contact the home domain for a fresh batch . A final remark on GSM has to do with the use of `` home-grown '' proprietary algorithms A3 , A5 and A8 to obtain authentication and secrecy . Hiding the algorithm is certainly contrary to the open-systems philosophy . Furthermore , the time-tried security-by-obscurity principle has not proven to be effective in preventing hostile attacks .2 3.2 CDPD Cellular Digital Packet Data -LRB- CDPD -RRB- architecture -LSB- 14 -RSB- has been recently developed by a consortium of several US-based companies . As the name suggests , it is oriented towards data , and not voice , traffic . CDPD takes advantage of free slots in cellular voice communication and uses them to transport data . Like UPT , it provides for network access through either mobile or fixed end-systems . However , it is not simply a valueadded service but a complete architecture including , among other things , a MAC layer . The architecture supports several network layer protocols including IP -LSB- 18 -RSB- and CLNP -LSB- 17 -RSB- . Security services in CDPD are composed of data confidentiality , key distribution and mobile unit authentication . CDPD requires a logically-distinct entity -LCB- Authentication Server -LRB- AS -RRB- -LCB- to be present in every CDPD domain -LRB- area -RRB- . An AS is typically co-located with the Mobile Data Intermediate System -LRB- MD-IS -RRB- in a service provider 's domain . Mobile unit -LRB- M-ES , in CDPD parlance -RRB- authentication always involves contacting the AS in the unit 's home domain . As shown in Figure 2 , the authentication process begins with the Diffie-Hellman key exchange protocol -LSB- 5 -RSB- . As a result , the M-ES and the serving MD-IS come to share a secret key , Ks .3 Armed with Ks , M-ES submits its credentials -LRB- encrypted with Ks -RRB- for authentication . The M-ES credentials consist of a triple : -LSB- NEI ; ARN ; ASN -RSB- . Exactly how ARN is generated is not specified . Presumably , it is an unpredictable random number produced by the home AS . However , ARN is not a true nonce4 since the same value of ARN may be used multiple times . The serving MD-IS decrypts the credentials and forwards them to the home MD-IS in the clear . The home MD-IS then validates the credentials and optionally issues a new ARN . M-ES authentication completes when the serving MD-IS receives a positive confirmation from the home MD-IS and signals to M-ES -LRB- enclosing the new ARN is applicable . -RRB- The M-ES authentication is unidirectional , i.e. , the serving MD-IS is not authenticated to the M-ES . This means that an intruder can masquerade as the serving MD-IS and discover the M-ES credentials .5 Like GSM , CDPD makes an assumption that the `` fixed '' network is secure . Therefore , communication between the serving MD-IS and the home MD-IS is conducted in the clear . Since this includes M-ES credentials -LSB- NEI ; ARN ; ASN -RSB- , CDPD is susceptible to the same attacks as GSM . In fact , GSM has a slight advantage over CDPD since , in GSM , the mobile station 's long-term key -LRB- Ki -RRB- is never revealed outside the station . Thus , anyone intercepting V LR$ HLR traffic can gain at most several authentication triplets : -LSB- RAND ; SRES ; Kc -RSB- and impersonate the mobile station as many times as there are triplets in the intercepted message . In contrast , CDPD does not require a long-term M-ES key . If an intruder intercepts M-ES credentials only once , he can impersonate the victim M-ES ad infinitum . This is because , the authenticators -LRB- ARN values -RRB- in CDPD are computed by the home AS -LRB- MD-IS -RRB- and not by the M-ES ; thus , mere possession of just one currently valid triplet -LSB- NEI ; ARN ; ASN -RSB- is enough to obtain subsequent triplets and continue impersonating the M-ES . To CDPD 's credit , it does not use proprietary encryption functions . As mentioned above , the initial key exchange is performed via Diffie-Hellman protocol . Subsequent traffic is encrypted using the -LRB- documented -RRB- RC4 encryption function -LSB- 24 -RSB- . 2If the recent Clipper proposal is any indication , the GSM `` secret '' solution also fails to give an informed end-user a comfortable feeling of security . 3There are actually two keys : K0 and K1 , both derived from Ks . They are used for MD-ES MD-IS and MD-ES ! MD-IS communication , respectively . 4An unpredictable , used-only-once random number -LSB- 9 -RSB- . 5GSM is slightly better off since after the initial MS authentication , the VLR must be able to decrypt incoming traffic with Kc ; which can only be obtained from the real HLR of the mobile unit . M-ESHome MD-IS HOTELVACANCY Serving MD-ISM-ES Hello -LRB- ESH -RRB- MD-IS Key Exchange -LRB- IKE -RRB- MD-ES Key Exchange -LRB- EKE -RRB- MD-IS Confirm -LRB- ISC -RRB- Redirection Confirm -LRB- RDC -RRB- Redirection Request -LRB- RDR -RRB- -LSB- NEI , ARN , ASN -RSB- Diffie-Hellman Key Exchangecompute Kscompute Ksoptional -LSB- NEI , ARN ' , ASN ' -RSB- NEI network equipment identifierARN authentication random numberASN authentication sequence numberM-ES mobile end-systemMD-IS mobile data intermediate systemMobile End-System Authentication in CDPDARN ' new ARNASN ' new ASN -LSB- NEI , ARN , ASN -RSB- validateRC4 -LRB- Ks , -LSB- NEI , ARN , ASN -RSB- -RRB- optional RC4 -LRB- Ks , -LSB- NEI , ARN ' , ASN ' -RSB- -RRB- Figure 2 : Mobile End-System Authentication in CDPD 3.3 UPT The upcoming European value-added service , Universal Personal Telecommunications -LRB- UPT -RRB- , is aimed primarily at the European market . It is designed to provide universal user access and to support both fixed and mobile end-systems . The UPT design anticipates many types of fraudulent use and suggests some general solutions ranging from simple PIN-based authentication to more involved two-way authentication -LRB- user $ UPT-equipment -RRB- using smartcards -LSB- 15 , 16 -RSB- . Unlike GSM , UPT has not matured to a state where specific security solutions have been proposed . 4 Authentication of Mobile Users In this section we develop a generic solution for the authentication of mobile users . In doing so we try to avoid the drawbacks of GSM and CDPD . In particular , we make no assumptions about the security of the intermediate , fixed networks . In addition , we take into account some usability concerns in order to minimize the burden on the user and provide a transparent user interface . 4.1 Initial Assumptions We assume that , when accessing the network in the home domain , the mobile user is authenticated with a traditional server-based authentication mechanism such as Kerberos -LSB- 3 -RSB- or KryptoKnight -LSB- 4 -RSB- . Users of every network domain are registered with that domain 's Authentication Server -LRB- AS -RRB- . The AS of a domain can be replicated or partitioned within the domain but the set of all partitioned and duplicated ASs represent a single domain-level authority . An important characteristic of mobile environments is the speed at which users move across domains in the network . We assume that the inter-domain travel has a relatively low frequency , i.e. , for a typical user , the intra-domain migrations -LRB- be it within a home or a remote domain -RRB- will be more frequent and last longer than the inter-domain migrations . 4.2 Design Criteria In addition to avoiding the aforementioned drawbacks of existing systems like GSM , the solution must take into account the following design criteria : ffl Domain Separation : Domain-specific secret or sensitive information such as the user 's secret key or password should not be propagated from the home domain to a foreign domain or between foreign domains . ffl Transparency to Users : Authentication in foreign domains should have minimal impact on the user interface with respect to authentication in the home domain . ffl User Identity Confidentiality : It is often desirable to keep both the movements and the current whereabouts of mobile users secret . For this reason , all user identification information must be protected from disclosure . ffl Minimal Overhead : The distance between the home and the foreign domain may be very large . Hence , the number of messages exchanged between the home domain and the remote domain for the purpose of authentication should be kept minimal . 4.3 Protocol Building Blocks We base our design on top of existing two - and three-party authentication and key distribution protocols . These protocols are borrowed from KryptoKnight , an authentication and key distribution service developed at IBM Research -LSB- 4 -RSB- . The reason for choosing KryptoKnight is twofold : a -RRB- Mutual Authentication Protocol A B A ; Nab > AUTHKab -LRB- Nab ; Nba ; B -RRB- ; Nba < ACKKab -LRB- Nab ; Nba ; A -RRB- > b -RRB- One-Way Authentication Protocol A B AUTHKab -LRB- Nab ; Ta ; B -RRB- ; Nab ; Ta > Figure 3 : KryptoKnight Two-Party Authentication Protocols ffl KryptoKnight protocols have a number of qualities that make them attractive to build on . These include : message compactness , usage of nonces -LRB- as opposed to timestamps -RRB- , formal assurance of security , use of strong one-way hash functions -LRB- as opposed to encryption -RRB- , protocol flexibility with respect to different network configurations , and amenability to small hardware-based implementations .6 ffl The resultant protocol -LRB- s -RRB- will be incorporated into the existing KryptoKnight protocol family -LRB- which currently lacks any support for user mobility . -RRB- In order to illustrate some KryptoKnight concepts , figure 3a illustrates the two-party mutual authentication protocol . AUTHKab denotes an authentication expression based on the shared key Kab . It is always generated by the responding party -LRB- B in our case -RRB- . This expression is computed as a result of applying a strong encryption function E , e.g. , DES -LSB- 6 -RSB- , with Kab as the encryption key , over three inputs : two nonces -LRB- Nab ; Nba -RRB- and the name of the message originator . One example of AUTH is :7 E -LRB- B LE -LRB- Nba LE -LRB- Nab -RRB- -RRB- -RRB- Similarly , ACKKab is the authentication expression that the initiating party computes in order to complete two-way authentication . It is computed over the same inputs except for the message originator 's name -LRB- A in this case . -RRB- An example of an ACK expression is : E -LRB- Nba LE -LRB- Nab -RRB- -RRB- Where mutual authentication is not desired , a one-way version of 2PAP can be used -LRB- see figure 3b . -RRB- The protocol is reduced to just one flow and one of the nonces in the authentication expression is replaced by the current timestamp . As described in the next section , elements of both mutual and one-way protocols are used in the design of the mobile user authentication protocol . 4.4 Basic Protocol The basic protocol is depicted in figure 4 . It enables a user presently located in a foreign domain to request the transfer of location-dependent authentication information from the authentication server of his home domain to its peer in the remote domain . In other words , the protocol 's purpose is to establish a temporary foreign residence for a travelling user . The following notation is used in the protocol and throughout the rest of this paper : 6Refer to -LSB- 4 -RSB- and -LSB- 19 -RSB- for details . 7All encryption is performed with Kab . ffl SUid , SUid -LCB- Identification of the end-user U in different protocol flows . The exact format is discussed in section 4.6.3 below . ffl ASh -LCB- Authentication Server of the home domain ffl ASr -LCB- Authentication Server of the remote domain ffl Ku -LCB- Key shared between U and ASh ffl Kur -LCB- Location-dependent key computed for the remote domain , i.e. , a key that user U can use only in domain R . The particulars of Kur computation are discussed below . ffl Krh -LCB- Long-term key shared by ASr and ASh . We assume that Krh is installed either out-of-band or using a secure key distribution procedure involving a mutually-trusted third party .8 ffl Ks -LCB- Short-term session key to be shared by ASr and U -LRB- generated by ASr . -RRB- ffl Nu -LCB- Nonce issued by user or by the access device on user 's behalf ffl Tu -LCB- Timestamp issued by the user or by the access device on his behalf ffl N1r -LCB- Nonce generated by ASr ffl AUTHK -LRB- X ; Y ; Z -RRB- -LCB- Authentication token computed over a triple -LRB- X ; Y ; Z -RRB- , under key K -LRB- as described in Section 4.3 . -RRB- ffl T ICK ^ K -LRB- A ; K ; B ; C -RRB- -LCB- A ticket -LRB- i.e. , a certificate -RRB- issued by A , sealed with the key ^ K , containing a secret quantity -LRB- typically , a key -RRB- K to be used by B for communicating with C . The exact format of a ticket is discussed below . + domain boundary U ASr ASh SU id ; Tu ; Nu ; N2r z -RCB- | -LCB- AUTHKur -LRB- Tu ; Nu ; U -RRB- > SUid ; ASr ; Tu ; Nu ; N1r , AUTHKrh -LRB- N1r ; N2r ; ASr -RRB- > T ICKKrh -LRB- ASh ; Kur ; ASr ; U -RRB- < T ICKKur -LRB- ASr ; Ks ; ASr ; U -RRB- < Figure 4 : Basic Mobile User Authentication Protocol Many variations of the basic protocol are possible . The main distinguishing factor of this particular version of the protocol is the computation of the domain-specific key Kur . It is computed as a strong oneway function over the foreign domain 's identity , user 's identity , and the permanent credential of the user which he uses at home -LRB- e.g. , a password -RRB- . This allows us to accommodate the least `` sophisticated '' user who relies only on his password or PIN and uses no special hardware to access the network , i.e. , no smart cellular phone , smartcard or token card . -LRB- However , users equipped with personal trusted hardware can still use the same key computation method . -RRB- In the weakest case , a user not having any special trusted hardware of his own , is forced to rely on whatever public access equipment is available , e.g. , a workstation or a simple 8This can be done with a hierarchy of ASs ; see , for example , -LSB- 25 -RSB- . terminal . In this case , all computation attributed to the user is actually performed by the access equipment on the user 's behalf . Of course , a user in possession of a trusted personal device can benefit from reduced exposure by having all or part of the computation take place on the device . We now turn to the details of the protocol : 1 . The user begins by generating a nonce Nu , a timestamp Tu and computing Kur . Next , he computes the authentication token AUTHKur -LRB- Nu ; Tu ; U -RRB- and sends it to the local AS , ASr . There are many ways of constructing Kur in a manner that makes it dependent on the user 's current location . For example , Kur can be computed as EKu -LSB- F -LRB- ASr ; U -RRB- -RSB- where F is a strong one-way hash function such as MD5 -LSB- 20 -RSB- . We can even avoid using encryption by computing Kur as F -LRB- ASr ; U ; Ku -RRB- . The use of encryption or a secret one-way function in the formation of Kur is essential in order to satisfy the domain separation constraint by preventing the derivation of Ku from Kur . Constructing Kur as described above has an important consequence that the user visiting the same domain on two different occasions will continue using the same Kur . At the first glance , this seems like a serious weakness . However , most users regularly change -LRB- or , at least , are expected to change -RRB- their passwords and PINs . A change of Ku in the home domain will invalidate any previously used Kur . If Ku is a weak key , e.g. , a password or a PIN , the authentication token -LRB- regardless of its construction details -RRB- is subject to verifiable-plaintext attack -LSB- 8 , 7 -RSB- . Little can be done to avoid this unless the access equipment maintains a secure channel to the local AS .9 Ideally , however , Ku is a strong key which , instead of being memorized by the user , is kept in secure storage on the user 's smartcard or some other type of personal device . For the purpose of the ensuing discussion , we assume that , the user and his/her device constitute a single entity . 2 . Upon receipt of the initial message , ASr recognizes that the user is a foreign one . Not having any means of authenticating/identifying this user , ASr needs to request a proof of the user 's identity from the claimed home location . The request must also authenticate ASr to ASh and U to ASh . The latter serves as evidence of U being in the remote domain . One obvious solution is to send two separate authentication tokens . However , the protocol must accommodate the environment where the user 's secret is weak and , as mentioned above , susceptible to guessing attacks . If a token computed with such a weak secret traverses a wide-area backbone comprised of potentially untrusted areas , the possibility of hostile attacks increases dramatically . For this reason , the user 's token is not actually sent in flow 2 . Instead , one of the two nonces used in the computation of the ASr token is the user token itself . This token chaining technique prevents guessing attacks on the user authentication token . This also has an advantage of reducing the size of the message in flow 2 . 3 . When ASh receives the message in flow 2 , it proceeds as follows : -LRB- a -RRB- Looks up the record for the user U and obtains Ku . -LRB- b -RRB- Validates Tu by comparing it to the current clock reading . Obviously , some skew is to be expected and a maximum clock difference must be defined accordingly . Tu is also compared to the last timestamp recorded in the user 's record . If the new timestamp is not greater than the recorded one , the request is rejected . -LRB- c -RRB- Given U , Ku and ASr , ASh recomputes Kur . -LRB- d -RRB- Using Kur , recomputes N2r = AUTHKur -LRB- Nu ; Tu ; U -RRB- . -LRB- e -RRB- Using N2r , N1r and ASr , recomputes AUTHKrh -LRB- N1r ; N2r ; ASr -RRB- and compares it to the corresponding token that arrived in flow 2 . A match in the last step successfully authenticates both U and ASr to ASh . At this point , ASh issues a ticket -LRB- in flow 3 -RRB- that confirms U 's identity and allows U to operate in the realm of ASr . A KryptoKnight-style ticket contains the following logical information : 9One could envision , for example , a physically secure , public access workstation that maintains a strong key in secure storage and uses that key to secure all communication with the nearest AS . ffl ticket issuer - ASh ffl issuer nonce - Nh ffl ticket reader - ASr ffl reader nonce - Nr ffl ticket third party - U ffl ticket key - Kur ffl expiration time10 and/or other metering information , e.g. , a spending limit . Not all of the above needs to be sent explicitly . In particular : ASh , ASr , U and Nr can be inferred from the context of the message , i.e. , the recipient -LRB- ASr -RRB- knows them . All ticket fields appear in cleartext with the exception of the key , which is secured within a key token . A KryptoKnight-style key token -LSB- 4 -RSB- , in turn , is computed as : AUTHKrh -LRB- Nr ; Nh ; U -RRB- LKur . This construction insures that the key is protected from unauthorized disclosure . Note that the integrity of the key is not guaranteed within the ticket , i.e. , the key token can be modified in transit . However , this does not present a problem since ASr confirms the goodness of Kur in the next protocol step -LRB- see below -RRB- . In total , all that is actually sent in flow 3 is Nh and the key token , i.e. : T ICKKrh -LRB- ASh ; Kur ; ASr ; U -RRB- = -LSB- Nh ; AUTHKrh -LRB- Nr ; Nh ; U -RRB- LKur -RSB- 4 . Upon receiving the message in flow 3 , ASr : -LRB- a -RRB- Recomputes AUTHKrh -LRB- Nr ; Nh ; U -RRB- -LRB- b -RRB- Extracts the key Kur -LRB- c -RRB- Recomputes AUTHKur -LRB- Nu ; Tu ; U -RRB- and , finally , compares it to the corresponding token received in flow 1 from U . This comparison is needed to check the integrity of Kur extracted from the ticket . A match in the last step is crucial . It completes the protocol cycle by authenticating to ASr both ASh and U simultaneously . Next , ASr proceeds to install the user 's temporary credentials in the subscriber/user database . We assume that a separate database of visiting users will be maintained -LRB- a VLR , in cellular parlance -RRB- . Of course , before installing the credentials , ASr has to be satisfied with the conditions accompanying the credentials , i.e. , validity interval , payment limit , etc. . 5 . The last flow -LRB- 4 -RRB- is strictly optional . It can be used to perform single sign-on for the user based on the information received from ASh , i.e. , to establish a working session key between ASr and U . The ticket is computed under the newly-acquired Kur and contains the strong session key -LRB- Ks -RRB- that the user can utilize immediately . 4.5 Subsequent Network Access For subsequent network access in the same domain , the foreign user can be authenticated via ordinary single sign-on protocol -LRB- e.g. , borrowed from KryptoKnight or Kerberos -RRB- using the same Kur .11 Of course , this can only happen within the limits of Kur lifetime . The only difference with respect to normal network access at home is that , while the user will continue utilizing his permanent secret Ku -LRB- as if he is in the home domain -RRB- , the actual key used in the single sign-on protocol will be Kur . This means that the user 's personal device or workstation must be programmed to calculate Kur accordingly . 4.6 Protocol Evaluation In this section we evaluate the proposed protocol along the lines of the previously stated design goals . 10The ticket lifetime should be chosen to be sufficiently long to cover the duration of a typical visit in a remote domain . 11Essentially , this means that only protocol flows 1 and 4 will be executed . 4.6.1 Domain Separation The protocol maintains domain separation by allowing a foreign domain to obtain a temporary key for a visiting user . The key is valid only within the domain it was issued for . Under no circumstances is the actual user 's key disclosed to the foreign domain . Of course , this argument becomes rather thin in the case of a user armed with only a weak password . -LRB- A malicious ASr can easily break Ku with a known-plaintext attack on Kur . -RRB- 4.6.2 User Transparency Provided that the end-user equipment is programmed accordingly , the fact that the authentication protocol is executed in a foreign domain makes very little difference from the user 's perspective . In the case of the unequipped user accessing the network through , say , a public workstation , the only difference for the user is having to enter : UserName@HomeDomain instead of the usual UserName The difference is even smaller for users equipped with personal devices . The device -LRB- e.g. , a cellular phone -RRB- can sense whenever it is no longer in a home domain and obtain the name of the local domain in the background , before the authentication protocol is initiated . It can similarly supply the name of its home domain ; thus , the user does not even have to enter it . 4.6.3 User Identity Confidentiality Until now we have sidestepped the issue of protecting the user 's identity . This issue is very important but can not be discussed thoroughly in this paper given that our main concern is with the authentication of mobile users . However , it is worth noting that many variables influence the way of protecting the user 's identity . In particular , a user armed with a personal device can benefit from the device 's ability to store arbitrary information . This can include , for example , a list of one-time pre-computed userids that a user can supply in place of his real identification . On the other hand , a user armed with only a password or a PIN has little recourse in safeguarding his identity . One possible solution is for each user to select a unique travelling alias , Ut -LRB- Ut can be assigned to a user by the home AS as well -RRB- . An alias can be similar in structure to a userid , e.g. , a user known as `` john.smith '' at home can select a Ut `` julius.caesar '' for use while travelling . The mapping between aliases and real user identities -LRB- U $ Tu -RRB- will be kept secret by the home AS . Users can be allowed and encouraged to change their aliases at regular intervals ; perhaps as often as passwords or PINs . Our discussion so far applies only to the first time a user pops up in a given foreign domain . Moreover , it applies only to the flow 1 of the authentication protocol where SUid field denotes the user 's identity . In the subsequent protocol flows , the obvious solution is to use the same SUid construction as in flow 1 . However , since ASr and ASh are assumed to share a strong secret key , Krh , the protection of the SUid field can be strengthened further . -LRB- This is completely independent of the way SUid is computed in Flow 1 . -RRB- One possibility is to set : SUid = EKrh -LRB- SUid -RRB- where SUid denotes the user identification field in flows 2 and 3 . However , this implies that ASh must decrypt SUid on receipt of message 2 . Since we would like to avoid explicit decryption operations , an alternative is : SUid = EKrh -LRB- AUTHKrh -LRB- N1r ; N2r ; ASr -RRB- -RRB- LSUid Once ASr authenticates the user -LRB- and ASh -RRB- in flow 3 and establishes a temporary record in its VLR , it can also assign a temporary identity to the user . This is different from the travelling alias referred to before . A temporary identity is issued by the local AS based on its own policy . It serves to identify a particular visit of a given user in a foreign domain and remains valid as long as the user 's entry in the VLR does not expire . 4.6.4 Low Overhead Given the initial requirement that the home domain be contacted to affirm the mobile user 's provenance -LRB- and solvency -RRB- , it is impossible to design a protocol with less than two flows traversing inter-domain boundaries , i.e. , ASr ! ASh and ASr ASh . In addition , at least one flow is necessary for the user to make initial contact with the local AS . This makes a minimum of three flows which is the number of flows in our protocol -LRB- the fourth flow is optional and local . -RRB- A closely-related issue is the size of each protocol flow . Of particular interest are the sizes of flows 2 and 3 since both cross domain boundaries and potentially traverse significant distances . The second flow -LRB- ASr ! ASh -RRB- is composed of six fields . If the user has a personal smartcard-like device , it is possible to maintain loosely-synchronized clocks between the device and ASh . This would allow ASr to omit the timestamp in flow 2 . -LRB- However , no clock synchronization between the device and ASr should be assumed . -RRB- The third flow -LRB- ASr ASh -RRB- contains a ticket which is logically comprised of six fields : ASh , Nh , ASr , Nr , SUid and Kur . -LRB- This excludes optional metering information , e.g. , ticket lifetime . -RRB- Of the six , ASr , Nr and ASh can be recovered from the context of the protocol run . In other words , if ASr retained state from flows 1 and 2 , it can recover these values . Hence , as few as three fields are actually necessary in the third flow . 5 Variations on the Theme 5.1 Doing Away with State One of the drawbacks of the basic protocol is the requirement that ASr retain state during the time between sending flow 2 and receiving flow 3 . There are some well-known benefits of stateless design ; code simplicity , storage conservation and increased fault-tolerance are chief among them . On the other hand , statefulness can result in shorter protocol messages , since when state is not retained it must be `` exported '' thus making messages longer . Moreover , it can be beneficial for ASr to retain state and actually create a database entry in a VLR before receiving confirmation from ASh in flow 3 . This could save time when flow 3 is finally received by ASr . In spite of all the pros and cons of state retention , we consider a stateless version of the protocol if only for the reason of completeness . As shown in figure 4 the user begins by sending a message to ASr . As before , ASr constructs the message in flow 2 , forwards it to ASh but does not keep any record of request in flow 1 . The exact contents of the message in flow 2 depend on the level of trust between the two domains . It is possible to leave the contents of flow 2 unchanged . In this case , when ASh replies in flow 3 , ASr is not able to authenticate the user directly -LRB- since all knowledge of flow 1 is lost . -RRB- Instead , ASr can go on with the protocol flow 4 , distributing a strong session key Ks and subsequently authenticate the user on the basis of Ks . Alternatively , it can ask the user to re-generate flow 1 . With a lower level of inter-domain trust ASr can `` piggyback '' the necessary state on top of flow 2 . This would entail including the entire contents of flow 1 . However , flow 2 already includes most of the components of flow 1 . The only information to be piggybacked is the user 's authentication token from flow 1 super-encrypted under a key Kr which is known only to ASr . The same token -LRB- as well as Tu and Nu -RRB- must also be included in flow 3 as shown in figure 5 . When ASr receives flow 3 it proceeds as before with one exception : when reconstructing the user 's authentication token with Kur , ASr must super-encrypt it with Kr and only then compare to EKr -LRB- N2r -RRB- received from ASh . This procedure still preserves the no decryption property of KryptoKnight protocols . U ASr ASh 1 . SUid ; Tu ; Nu ; N2r z -RCB- | -LCB- AUTHKur -LRB- Tu ; Nu ; U -RRB- > 2 . SUid ; ASr ; Tu ; Nu ; N1r ; EKr -LRB- N2r -RRB- , AUTHKrh -LRB- N1r ; N2r ; ASr -RRB- > 3 . TICKKrh -LRB- ASh ; Kur ; ASr ; U -RRB- ; EKr -LRB- N2r -RRB- ; Tu ; Nu < 4 . TICKKur -LRB- ASr ; Ks ; ASr ; U -RRB- < Figure 5 : Stateless authentication protocol 5.2 Wireless/Cellular Considerations In a highly-dynamic wireless environment where users frequently cross domain boundaries in the middle of communication , it is crucial to transfer the necessary state between domains in a manner transparent to the user . The same problem also occurs when users migrate among different cells within the same domain . However , in the latter case , authentication is not an issue . GSM , for example , makes provisions for very fast transfer of users ' authentication information between domains . Recall that -LRB- as described in section 3 -RRB- in GSM the home domain supplies the foreign domain with a set of challenge/response pairs .12 Each pair is good for one-time authentication of the user . Whenever the user moves from foreign domain A to foreign domain B , ASa is allowed to forward the unused challenge/response pairs to ASb . This allows ASb to authenticate the user -LRB- or , rather , the user 's SIM -RRB- immediately without having to contact the home domain . On the other hand , as discussed in Section 3.1 , GSM assumes that the fixed network is secure and communication between the MSCs -LRB- ASs -RRB- is conducted in the clear . This assumption is valid only in homogenous mobile-user environments such as GSM or CDPD . Also , when the entire set of authentication triplets has been depleted , there is no way for the visited domain -LRB- ASb -RRB- to authenticate the visiting user without contacting the home domain again . Figure 6 depicts a fast hand-over protocol . The first two flows represent a normal user sign-on in the foreign domain A . These flows are identical to flows 1 and 4 in the basic protocol . Subsequently , the user is crossing the boundary into the adjacent foreign domain B. Instead of immediately contacting ASh -LRB- which is potentially very far away -RRB- , ASa forwards to ASb a ticket containing the very same key Ks that was distributed to the user in flow 2 of the last network sign-on in A. Knowing Ks allows ASb to authenticate the user immediately and directly .13 However , this protocol is only useful as a temporary measure . It is expected that the next time the user attempts to access the network in domain B , a full-fledged authentication procedure involving the home domain will take place . 6 Summary In conclusion , this paper discussed security implications of user mobility in both wireline and wireless network environments . Existing approaches such as GSM and CDPD were found to be ill-suited for general mobile user authentication . After formulating a number of important design goals , we presented a new 12In message flow 3 , figure 1 . 13The ticket forwarded to ASb must have a very short lifetime . U ASa ASb SUid ; Tu ; Nu ; N2r z -RCB- | -LCB- AUTHKur -LRB- Tu ; Nu ; U -RRB- > TICKKur -LRB- ASa ; Ks ; ASa ; U -RRB- < . . . TICKKab -LRB- ASa ; Ks ; ASb ; U -RRB- > . . . One-way or mutual authentication with Ks < > Figure 6 : Fast Hand-over of Authentication Information protocol for cross-domain authentication of mobile users . The flexibility of the proposed solution allows its implementation -LRB- irrespective of the underlying network design specifics -RRB- in any environment that supports user mobility . Authentication protocols described in this paper have been implemented as part of KryptoKnight Network Security Server . The current operating environment supports user mobility via traditional , wireline access . Future work includes experimentation with wireless access . 7 Acknowledgements The authors are grateful to Els Van Herreweghen , Ralf Hauser , Phil Janson and Liba Svobodova for many useful comments and suggestions . We are also indebted to the referees -LRB- who shall remain nameless -RRB- for their valuable input . References -LSB- 1 -RSB- M. Rahnema , Overview of the GSM System and Protocol Architecture , IEEE Communications Magazine , April 1993 . -LSB- 2 -RSB- B. Mallinder An Overview of the GSM System , Proceedings of Digital Cellular Radio Conference , October 1988 . -LSB- 3 -RSB- J. Steiner , C. Neuman , J. Schiller , Kerberos : An Authentication Service for Open Network Systems , Proceedings of USENIX Winter Conference , February 1988 . -LSB- 4 -RSB- R. Molva , G. Tsudik , E. Van Herreweghen , S. Zatti , KryptoKnight Authentication and Key Distribution Systems , Proceedings of ESORICS ' 92 , November 1992 . -LSB- 5 -RSB- W. Diffie and M. Hellman , New Directions in Cryptography , IEEE Transactions on Information Theory , November 1976 . -LSB- 6 -RSB- National Bureau of Standards , Federal Information Processing Standards , National Bureau of Standards , Publication 46 , 1977 . -LSB- 7 -RSB- T. Lomas , L. Gong , J. Saltzer , R. Needham , Reducing Risks from Poorly Chosen Keys , Proceedings of ACM Symposium on Operating System Principles , 1989 . -LSB- 8 -RSB- L. Gong , T. Lomas , R. Needham , J. Saltzer , Protecting Poorly-Chosen Secrets from Guessing Attacks , IEEE Journal on Selected Areas in Communications , to appear in Spring 1993 . -LSB- 9 -RSB- R. Needham and M. Schroeder , Using Encryption for Authentication in Large Networks of Computers , Communications of the ACM , December 1978 . -LSB- 10 -RSB- R. Rivest , A. Shamir and L. Adleman , A Method for Obtaining Digital Signatures and Public Key Cryptosystems , Communications of the ACM , February 1978 . -LSB- 11 -RSB- J. Linn Privacy Enhancement for Internet Electronic Mail . Parts I : Message Encryption and Authentication Procedures , RFC-1421 , SRI Network Information Center , February 1993 . -LSB- 12 -RSB- S. Kent Privacy Enhancement for Internet Electronic Mail . Parts II : Certificate-Based Key Management , RFC - 1422 , SRI Network Information Center , February 1993 . -LSB- 13 -RSB- D. Balenson Privacy Enhancement for Internet Electronic Mail . Parts III : Algorithms , Modes , and Identifiers , RFC-1423 , SRI Network Information Center , February 1993 . -LSB- 14 -RSB- Cellular Digital Packet Data -LRB- CDPD -RRB- System Specification , Release 1.0 , July 19 , 1993 . -LSB- 15 -RSB- European Telecommunications Standards Institute , Universal Personal Telecommunications , ETSI NA7 WP1 , November 1992 . -LSB- 16 -RSB- European Telecommunications Standards Institute , Universal Personal Telecommunications , ETSI NA7 TS 02.03 , January 1992 . -LSB- 17 -RSB- International Standards Organization , Information Processing Systems -LCB- Open Systems Interconnection -LCB- Basic Reference Model , ISO 7498 , 1977 -LSB- 18 -RSB- J. Postel , Internet Protocol , RFC 791 , SRI Network Information Center , September 1981 . -LSB- 19 -RSB- R. Bird , I. Gopal , A. Herzberg , P. Janson , S. Kutten , R. Molva , M. Yung , Systematic Design of Two-Party Authentication Protocols , Proceedings of Crypto ' 91 , August 1991 . -LSB- 20 -RSB- R. Rivest , The MD5 Message Digest Algorithm , Internet DRAFT , July 1991 . -LSB- 21 -RSB- D. Chaum , A. Fiat and M. Naor , Untraceable Electronic Cash , Proceedings of Crypto ' 88 , August 1988 . -LSB- 22 -RSB- D. Chaum , Security Without Identification : Transactions Systems to Make Big Brother Obsolete , CACM Vol . 28 , No. 10 , October 1985 . -LSB- 23 -RSB- CCITT , The Directory Authentication Framework , CCITT Recommendation X. 509 , 1988 . -LSB- 24 -RSB- RSA Data Security Inc. , The RC4 Encryption Algorithm , Document No. 003-013005-100-000-000 , March 12 , 1992 . -LSB- 25 -RSB- K. Sollings , Cascaded Authentication , Proceedings of 1987 IEEE Symposium on Security and Privacy , April 1987 .

B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O B O O O O O O O O O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O B O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O B O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O B O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O B O B I O O O O O O O O O O B O B I O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O B I O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O

authentication
cdpd
gsm
internetworks
mobile users
mobility
network security
upt

interdomain protocols
network services
roaming