US20090119742A1 - Methods for authenticating and authorizing a mobile device using tunneled extensible authentication protocol - Google Patents

Abstract

Methods for authenticating and authorizing a mobile device using tunneled extensible authentication protocol are provided. The methods include evaluating an inner user identifier against a policy engine to determine a home AAA server to route an access request for inner user authentication. Instead of having a static route configured based on an outer identifier/roaming identity, the policy engine can have multiple rules and actions for routing the request. The evaluation can be based on the conditions of the inner user identifier and or other AAA attributes received in the request. The request is transmitted within a secure communication tunnel. There are several embodiments of evaluating an inner user identifier against a policy engine.

Description

BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• The present invention relates to mobile communications, and more particularly, to authenticating and authorizing a mobile device using tunneled EAP.
• 2. Background of Invention
• An increasingly large number of individuals use portable computing devices, such as laptop computers, personal data assistants (PDAs), smart phones and the like, to support mobile communications. The number of computing devices, and the number of networks that these devices connect to, has increased dramatically in recent years.
• In a typical wireless Internet environment, Wi-Fi based hotspots could be adjacent or distributed in cellular telephone networks. When the services of wireless LAN and cellular networks are integrated, the mobile device (e.g., laptop computer) can move across networks. There are two types of roaming: roaming between the same type of network (e.g., wireless LAN to wireless LAN or cellular network to cellular network) is defined as horizontal roaming; roaming between different types of networks, such as a wireless LAN and a cellular network, is defined as vertical roaming.
• The service provider allowing access to its network usually requires a mobile node and/or a mobile user to authenticate that it is entitled to access the network before it is granted network access. Authentication is the process of identifying a device or user. For example, when logging on to a computer network, user authentication is commonly achieved using a username and password. Authentication is distinct from authorization, which is the process of giving devices or individuals access to services and features based on their identity. Authentication merely ensures that an individual is who he or she claims to be, but does not address the access rights of the individual.
• Accordingly, a wireless network generally includes many wireless nodes and users trying to gain access to a network. The primary means for controlling access include network access servers (“NAS”) and authentication servers, such as authentication, authorization, accounting (AAA) servers. A NAS, which is also referred to as an access point, provides access to the network. The devices and users connect through an access point via some form of wireless connection (e.g. IEEE 802.1X) to obtain access to a network (e.g., the Internet). In typical installations, there is a local authentication server, which allows the user to authenticate the network and a user's home authentication server that authenticates the user. The authentication servers are typically RADIUS (Remote Authentication Dial-In User Service) or Diameter servers.
• In this type of network access server environment, a version of the Extensible Authentication Protocol (EAP) is typically used for network authentication. For further information regarding EAP, see e.g., “RFC 3748: Extensible Authentication Protocol,” by the Internet Engineering Task Force (IETF), the disclosure of which is hereby incorporated by reference. EAP is a general protocol for authentication, which supports multiple authentication mechanisms. The client devices and the authentication server (e.g., RADIUS or DIAMTER server) exchange EAP messages by embedding them as attributes of a RADIUS packet. For further information regarding RADIUS, see, e.g., “RFC 2865: Remote Authentication Dial In User Service (RADIUS),” by the IETF, the disclosure of which is hereby incorporated by reference. See also, “RFC 4072: Diameter Extensible Authentication Protocol (EAP) Application, by the IETF, the disclosure of which is hereby incorporated by reference.
• Certain TLS (Transport Layer Security) based Extended Authentication Protocols optionally allow user authentication to occur within the protected tunnel. EAP-TTLS (Extended Authentication Protocol Tunneled Transport Layer Security) and PEAP (Protected Extended Authentication Protocol) are EAP protocols that are authentication tunneling protocols that create a protected channel for user authentication. These protocols use a two-phase authentication approach. In the first phase, the mobile device authenticates the foreign network, that is, the mobile device uses a digital certificate to ensure that the foreign network is legitimate. After the foreign network is authenticated, an encrypted channel between the mobile device and the mobile device's home AAA (i.e. AAA/H) is established using TLS and the information provided in the digital certificate. In the second phase, user information (e.g. Inner-User-ID) is securely transmitted using the established TLS-encrypted channel. The foreign network can authenticate the user from the user information using an inner user authentication method (e.g. PAP(Password Authentication Protocol), CHAP(Challenge-handshake authentication protocol), EAP, MSCHAPv1 (Microsoft Challenge handshake authentication protocol) and MSCHAPv2). The authentication can be carried out either by a TLS-AAA (the TLS end point of the foreign network) or by a remote AAA/H. For PEAP, this inner user authentication method typically must be another EAP authentication method. For further information about EAP-TTLS, see, Internet Draft EAP Tunneled TLS Authentication Protocol Version 0 (draft-funk-eap-ttls-v0), which is hereby incorporated by reference. For further information about PEAP, see Internet Draft PEAP (draft-josefsson-pppext-eap-tls-eap-06.txt), which is hereby incorporated by reference.
• In the two-phase authentication protocols, such as those described above, the foreign network must know how to route user information to the user's home server. In prior art systems, routing is typically achieved using static routes configured based on generic information transmitted between the mobile the device and foreign network during the first phase of the authentication process. In prior art systems, the foreign network routes the inner user authentication information using the outer identity/roaming identity used by the mobile device to authenticate the foreign network, in some cases even before inner user information is known. For example, the foreign network may have a list associating outer identities to home servers (e.g. outer identity user@IPprovider is routed to home server IPprovider). This front end approach can be problematic because it may be desirable to route a user's inner user authentication information to a AAA server other than the general AAA server.
• What is needed are methods for wireless Internet environments that provide increased flexibility for authenticating a user.
SUMMARY OF THE INVENTION
• The present invention provides systems and methods for a foreign network to route user authentication information to a particular home server using a tunneled Extensible Authentication Protocol (EAP).
• The invention includes evaluating inner user information against a policy engine to determine which AAA server to route the request to for inner user authentication. Instead of having a static route configured based on the outer identity/roaming identity, the EAP policy can have multiple rules and actions to route the request. The evaluation can be based on the conditions on inner user evaluation and or other AAA attributes received in the request. Using this backend policy approach to evaluate the inner user information simplifies upfront EAP based TLS policy evaluation. Further, because inner user information is not known until later in an EAP based TLS protocol exchange, the present invention allows for a highly flexible routing scheme to be employed to determine the appropriate AAA server.
• In an embodiment, the TLS-AAA evaluates the embedded user name attribute (used in legacy authentication protocols such as PAP, CHAP, etc.) against a local policy to determine which AAA/H to route the embedded user name to.
• In an embodiment, the TLS-AAA evaluates the inner EAP-Identity (for EAP authentication protocols) or inner user identity (for PAP, CHAP, MSCHAPv1/v2 authentication protocols) to determine which AAA/H to route the inner user identifier to by evaluating it against a local policy.
• In an embodiment, the policy engine places one or more of the following conditions on the inner user identifier:
• Equals
• StartsWith
• EndsWith
• Contains
• Regular expression, and
• Appears.
• In an embodiment, the mobile node includes, but is not limited to laptop computers, cellular phones, smart phones, and personal data assistants.
• In an embodiment, the implementation is based on a generic network access via the RADIUS protocol. The network access type can be of various types i.e. WiFi, WiMAX, wireline, etc. It can also be extended for applications requiring AAA authentications.
• In an embodiment, a policy engine is placed at any server where authentication is tunneled for a mobile device such that a request can be directed or redirected to a particular AAA server based on a condition.
• Further embodiments, features, and advantages of the invention, as well as the structure and operation of the various embodiments of the invention are described in detail below with reference to accompanying drawings.
BRIEF DESCRIPTION OF THE FIGURES
• The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. The drawing in which an element first appears is indicated by the left-most digit in the corresponding reference number.
• FIG. 1 provides a network diagram of a portion of a roaming environment.
• FIG. 2 provides a prior art method for authenticating and authorizing a mobile device using tunneled EAP.
• FIG. 3 provides a method for a TLS AAA server to evaluate a mobile device's access request in a communication network using EAP, according to an embodiment of the invention.
• FIG. 4 is a diagram of a computer system on which the methods and systems herein described can be implemented, according to an embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
• While the present invention is described herein with reference to illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the invention would be of significant utility.
• FIG. 1 provides a network diagram of a portion of aroaming environment100. The diagram provides a simplified network view that can be used to illustrate the authentication procedures needed when a mobile device roams from one network to another. In the example ofFIG. 1,mobile devices110aand110bseek network access to wireless LANhot spot140.Access point120 and visited Authentication, Authorization, Accounting (AAA)server130 within wireless LANhot spot140 support access and authentication of mobile users. VisitedAAA server130 is coupled tohome AAA servers160a,160b,and160cvianetwork150.Home AAA servers160a,160b,and160care located withinrespective home network170a,170b,and170c.Home AAA servers are associated with particular mobile devices. Thus, for each mobile device that attempts to access thenetwork140 there are several potential home AAA servers that the mobile device's request may be potentially routed to. For the purposes of authentication, amobile device110 can be wirelessly coupled toaccess point120 using EAP.
• EAP provides an authentication framework that supports multiple authentication methods. EAP typically runs directly over data link layers, such as point-to-point protocol (“PPP”) or IEEE 802.1X, without requiring internet protocol (“IP”). EAP may be used on dedicated lines, as well as switched circuits, and wired as well as wireless links. Deployments of IEEE 802.11 wireless LANs are based on EAP and use several EAP methods, including EAP-TLS (Transport Level Security), EAP-TTLS (Tunneled Transport Level Security), PEAP (Protected Extensible Authentication Protocol), and EAP-SIM (Subscriber Identify Module). These methods support authentication credentials that include digital certificates, user-names and passwords, secure tokens, and SIM secrets. The present invention can be implemented with each of these methods, but is not limited to these methods. Furthermore, the embodiments discussed herein focus on wireless links, however, the scope and spirit of the present invention extends to wired links, as well.
• Using EAP nomenclature, amobile device110 is considered an EAP peer, whileaccess point120 is considered an EAP authenticator and aTLS AAA server130 and ahome AAA server160 is considered an EAP authentication server.
• One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism, typically after the authenticator requests more information in order to determine the specific authentication method to be used. Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server, which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and peers.
• Referring toFIG. 1, when amobile device110 attaches to accesspoint120, it needs to authenticate with itshome AAA server160 before network access is granted. The authentication is based on EAP andmobile device110, visitedTLS AAA server130 andhome AAA server160 take on EAP roles, as identified above. EAP messages are transported between themobile device110 acting as an EAP Peer to theaccess point120, the EAP Authenticator, using any of many transport methods, such as 802.1x, PANA, and the like. The transport betweenaccess point120 and ahome AAA server160 is typically carried over AAA protocol using RADIUS or Diameter. The EAP messages travel through a visitedAAA server130, zero or more broker AAA server(s) (not shown) and finally arrive at thehome AAA server160. It should be noted that broker AAA servers may also be present betweenaccess point120 andTLS AAA server130 and simply operate in a pass through mode.
• FIG. 2 illustrates a prior art method for authenticating and authorizing amobile device110 using tunneled EAP.Method200 begins instep210.
• Instep210,access point120 receives an EAP-Start message. This message comes from thenetwork140 and signals that the EAP procedure should start.
• Instep220access point120, which is located in the visitednetwork140, issues an EAP-Request-Identity message. Ifaccess point120 knows the visited network Authentication Policy, it will encode the policy as part of the EAP-Request-Identity message. The coding of the message will be similar to the encoding used in “RFC 4284: Identity Selection Hints for the Extensible Authentication Protocol (EAP),” by the IETF, the disclosure of which is hereby incorporated by reference and will be known to individuals skilled in the relevant arts based on the teachings herein and reference to RFC 4284.
• Instep230, themobile device110 receives the EAP-Request-Identity.Mobile device110 decodes the message to learn the authentication policy of the visitednetwork140.Mobile device110 uses that knowledge and the preconfigured knowledge of the authentication policy of its home network170 to select the authentication policy required.Mobile device110 encodes the authentication policy in an EAP-Response-Identity message and sends the message to accesspoint120. As shown inFIG. 2, the EAP-Response-Identity message can include an outer/realm identity (“user@realm”). This identity is not specific to the user and is not transmitted within a secure tunnel.
• Instep240,TLS AAA server130 decodes the EAP-Response Identity message.
• Instep245,TLS AAA server130 responds to the message with an access challenge message. Access challenge includes information that allowsnetwork140 to be authenticated bymobile device110, i.e. a digital certificate that lets mobile device know thatnetwork140 is legitimate.
• Instep250, a tunnel is established so that user specific information (e.g. User-Name and password) can be securely transmitted between theTLS AAA server130 andmobile device110. The tunnel is established betweenmobile device110,access point120, andTLS AAA server130. The inner User-Name/inner EAP-Identity and password information is secure within this tunnel.
• Instep260,TLS AAA server130 receives a message containing the user specific information. The information in the message is particular to the authentication method that will be used to authenticate the user (e.g. PAP, CHAP, EAP, MSCHAPv1, MSCHAPv2). The authentication method to be used is established in the steps beforestep260. TheTLS AAA130 may decide to forward the request toHome AAA server160 to complete phase2 of the authentication. It should be noted thatTLS AAA130 andHome AAA160 may be the same process/application.
• Atstep270,Home AAA server160, may act as the EAP Authentication Server, for example, then starts to execute an EAP method appropriate to the authentication method selected. The EAP method continues to execute until it succeeds or fails. In the case of PAP, CHAP, MSCHAPv1, and MSCHAPv2,Home AAA server160 will authenticate the user based on the received protocol attribute information and will either accept or reject the session.Steps280 and290 illustrate a successful authentication occurring that enablesmobile device110 to accessnetwork140. Specifically, instep290mobile device110 receives an EAP-Success message. If successful authentication does not occur, ultimately the process will time out.
• FIG. 3 provides amethod300 for a TLS AAA server to evaluate a mobile device's access request in a communication network using EAP, according to an embodiment of the invention.Method300 begins instep310.
• Instep310,access point120 receives an EAP-Start message. This message comes from thenetwork140 and signals that the EAP procedure should start.
• Instep320,access point120, which is located in the visitednetwork140, issues an EAP-Request-Identity message. Ifaccess point120 knows the visited network Authentication Policy, it will encode the policy as part of the EAP-Request-Identity message.
• Instep330, themobile device110 receives the EAP-Request-Identity.Mobile device110 decodes the message to learn the authentication policy of the visitednetwork140.Mobile device110 uses that knowledge and the preconfigured knowledge of the authentication policy of its home network170 to select the authentication policy required.Mobile device110 encodes the authentication policy in an EAP-Response-Identity message and sends the message to accesspoint120. As shown inFIG. 3, the EAP-Response-Identity message can include an outer/realm identity (“user@realm”). This identity is not specific to the user and as such may not be secure.
• Instep340,TLS server130 decodes the EAP-Response Identity message.
• Instep350,TLS AAA server130 responds to the message with an access challenge message. Access challenge includes information that allowsnetwork140 to be authenticated bymobile device110, i.e. a digital certificate that lets mobile device know thatnetwork140 is legitimate.
• Instep360, a tunnel is established which allows user specific information (e.g. User-Name and password) to be securely transmitted betweenTLS server130 andmobile device110. The tunnel is established betweenmobile device110,access point120, andTLS AAA server130. The inner User-Name/inner EAP-Identity and password information is secure within this tunnel.
• Instep370,TLS AAA server130 receives a message containing the user specific information. The information in the message is particular to the authentication method that will be used to authenticate the user (e.g. PAP, CHAP, EAP, MSCHAPv1, MSCHAPv2). The authentication method to be used is established in the steps beforestep370.
• Instep380, theTLS AAA server130 will evaluate the embedded user specific information to determine which Home AAA server to route the user specific information to by evaluating it against a local policy. For example, theTLS AAA server130 will evaluate the embedded User-Name attribute for legacy authentication protocols (PAP, CHAP, etc.) or the EAP-Identity for EAP authentication protocols.
• The policy engine can place one or more of the following conditions on an inner user identifier:
• Equals
• Starts with
• Ends with
• Contains
• Regular expression; and
• Appears
• An “equals” condition tests if an inner user identifier is the same as a predetermined string. An example of the “equals” condition is as follows: when the “equals” condition is “abc”, inner user identifier “abc” satisfies the condition and inner user identifier “abcd” does not.
• A “starts with” condition tests if a character string at the beginning of the an inner user identifier is the same as a predetermined string. An example of the “starts with” condition is as follows: when the “starts with” condition is “abc”, inner user identifier “abcd” satisfies the condition and inner user identifier “dabc” does not.
• An “ends with” condition tests if a character string at the end of an inner user identifier is the same as a predetermined string. An example of the “ends with” condition is as follows: when the “ends with” condition is “abc”, inner user identifier “deabc” satisfies the condition and inner user identifier “abcde” does not.
• A “contains” condition tests if one or more characters are contained in an inner user identifier. An example of the “contains” condition is as follows: when the “contains” condition is abc, inner user identifier “xyabce” satisfies the condition and inner user identifier “axybec” does not.
• A “regular expression” holds a regular expression that is used to match a pattern against an inner user identifier.
• An “appears” command tests if an attribute appears in the an Access-Request message.
• It should be noted that the commands described above are for exemplary purposes only and that the policy engine can implement any number of different types of tests on information received frommobile device110 as would be appreciated by one of ordinary skill in the art.
• Instep390, after inner user identifier is evaluated against a policy. The user information is forwarded to the appropriate home server as determined by policy evaluation or the TLS AAA policy may determine that the user information is to be processed locally, in otherwords the TLS AAA may also be the home AAA.
• Referring toFIG. 1, an example ofsteps380 and390 is as follows: Suppose the UserID for mobile device user ofmobile device110ais johnsmith@realm.com. Suppose AAA/H servers160a,160b,and160ceach store user authentication information based the user's last name contained in the UserName, whereserver160astores user authentication information for users with last names A-J,server160bstores user authentication information for users with last names K-T, andserver160cstores user authentication information for users with last names U-Z. Policy engine can search the user name johnsmith for an last name using the commands described above and route the user authentication information toserver160b,which would contain the user authentication information for user John Smith.
• Atstep392,Home AAA server160, acting as the EAP Authentication Server, for example, then starts to execute an EAP method appropriate to the authentication method selected. The EAP method continues to execute until it succeeds or fails. In the case of PAP, CHAP, MSCHAPv1, and MSCHAPv2,Home AAA server160 will authenticate the user based on the received protocol attribute information and will either accept or reject the session.Steps394 and396 illustrate a successful authentication occurring that enablemobile device110 to access network170. Specifically, instep396mobile device110 receives an EAP-Success message. If successful authentication does not occur, ultimately the process will time out.
• It should be appreciated thatstep380 can be incorporated into prior art method in a variety of ways. For example, a policy engine could be incorporated into a home AAA server that initially receives the inner user identifier based on outer/realm identifier as described in accordance withFIG. 2. After the home AAA server evaluates the inner user identifier it could forward the inner user identifier to another preferred/more appropriate home AAA server based on the evaluation.
Computer System Implementation
• In an embodiment of the present invention, the methods and systems of the present invention described herein are implemented using well known computers, such as acomputer400 shown inFIG. 4. Thecomputer400 can be any commercially available and well known computer capable of performing the functions described herein, such as computers available from International Business Machines, Apple, Sun, HP, Dell, Cray, etc.
• Computer400 includes one or more processors (also called central processing units, or CPUs), such asprocessor410.Processor410 is connected tocommunication bus420.Computer400 also includes a main orprimary memory430, preferably random access memory (RAM).Primary memory430 has stored therein control logic (computer software), and data.
• Computer400 may also include one or moresecondary storage devices440.Secondary storage devices440 include, for example,hard disk drive450 and/or removable storage device or drive460.Removable storage drive460 represents a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup, ZIP drive, JAZZ drive, etc.
• Removable storage drive460 interacts withremovable storage unit470. As will be appreciated,removable storage unit460 includes a computer usable or readable storage medium having stored therein computer software (control logic) and/or data.Removable storage drive460 reads from and/or writes to theremovable storage unit470 in a well known manner.
• Removable storage unit470, also called a program storage device or a computer program product, represents a floppy disk, magnetic tape, compact disk, optical storage disk, ZIP disk, JAZZ disk/tape, or any other computer data storage device. Program storage devices or computer program products also include any device in which computer programs can be stored, such as hard drives, ROM or memory cards, etc.
• In an embodiment, the present invention is directed to computer program products or program storage devices having software that enablescomputer400, or multiple computer400s to perform any combination of the functions described herein
• Computer programs (also called computer control logic) are stored inmain memory430 and/or thesecondary storage devices440. Such computer programs, when executed,direct computer400 to perform the functions of the present invention as discussed herein. In particular, the computer programs, when executed, enableprocessor410 to perform the functions of the present invention. Accordingly, such computer programs represent controllers of thecomputer400.
• Computer400 also includes input/output/display devices480, such as monitors, keyboards, pointing devices, etc.
• Computer400 further includes a communication ornetwork interface490.Network interface490 enablescomputer400 to communicate with remote devices. For example,network interface490 allowscomputer400 to communicate over communication networks, such as LANs, WANs, the Internet, etc.Network interface490 may interface with remote sites or networks via wired or wireless connections.Computer400 receives data and/or computer programs vianetwork interface490. The electrical/magnetic signals having contained therein data and/or computer programs received or transmitted by thecomputer400 viainterface490 also represent computer program product(s).
• The invention can work with software, hardware, and operating system implementations other than those described herein. Any software, hardware, and operating system implementations suitable for performing the functions described herein can be used.
Conclusion
• Exemplary embodiments of the present invention have been presented. The invention is not limited to these examples. These examples are presented herein for purposes of illustration, and not limitation. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the invention.

Claims (14)

1. In a communications network using an Extensible Authentication Protocol (EAP), a method for a routing a client access request to a home Authentication, Authorization, and Accounting (AAA) server for inner user authentication, comprising:

(a) establishing a transport layer security (TLS) tunnel between a visited AAA server in a foreign network and the client;

(b) receiving an access request from the client at the visited AAA server within the TLS tunnel;

(c) evaluating attributes received in the access request at the TLS AAA server against a local policy; and

(d) routing said access request to a home authentication server based at least in part on the evaluation of attributes received in said access request against said local policy.

2. The method ofclaim 1, wherein attributes received in said access request include an inner user identifier and wherein evaluating attributes received in said access request includes evaluating the inner user identifier against said local policy.

3. The method ofclaim 1, wherein a client comprises a cellular telephone, a smart phone, a laptop computer, or a personal data assistant.

4. The method ofclaim 2, wherein evaluating the inner user identifier against said local policy comprises performing at least one of the following determinations on the inner user identifier:

(a) determining if the inner user identifier equals a known character string;

(b) determining if a prefix portion of the inner user identifier equals a known character string;

(c) determining if a suffix portion of the inner user identifier equals a known character string; and

(d) determining if the inner user identifier contains a characters in a defined set of characters.

5. The method ofclaim 1, wherein establishing a transport layer security (TLS) tunnel between a visited AAA server in a foreign network and the client includes establishing the TLS tunnel according to one of EAP-TTLS or PEAP protocols.

6. The method ofclaim 1, wherein evaluating attributes received in the access request at the TLS AAA server against a local policy includes evaluating a EAP-Identity in the access request.

7. The method ofclaim 6, wherein evaluating a EAP-Identity includes performing at least one of the following determinations on the inner user identifier:

(a) determining if the EAP-Identity equals a known character string;

(b) determining if a prefix portion of the EAP-Identity equals a known character string;

(c) determining if a suffix portion of the EAP-Identity equals a known character string; and

(d) determining if the EAP-Identity contains a characters in a defined set of characters.

8. The method ofclaim 1, wherein evaluating attributes received in the access request at the TLS AAA server against a local policy includes evaluating a User-Name attributes in the access request, wherein User-Name attribute is defined by any one of PAP, CHAP, MSCHAPv1, or MSCHAPv2 protocols.

9. The method ofclaim 8, wherein evaluating a User-Name includes performing at least one of the following determinations on the inner user identifier:

(a) determining if the User-Name equals a known character string;

(b) determining if a prefix portion of the User-Name equals a known character string;

(c) determining if a suffix portion of the User-Name equals a known character string; and

(d) determining if the User-Name contains a characters in a defined set of characters.

10. In a communications network using an authentication protocol, a method for a routing a client access request to a home authentication server for inner user authentication, comprising:

(a) establishing a secure communication tunnel between a visited server and the client;

(b) receiving an access request from the client at the visited server within said secure communication tunnel;

(c) evaluating attributes received in said access request at said visited server against a local policy; and

(d) routing said access request to a home authentication server based at least in part on the evaluation of attributes received in said access request against said local policy.

11. The method ofclaim 10, wherein attributes received in said access request include an inner user identifier and wherein evaluating attributes received in said access request includes evaluating the inner user identifier against said local policy.

12. The method ofclaim 10, wherein evaluating the inner user identifier against said local policy comprises performing at least one of the following determinations on the inner user identifier:

(a) determining if the inner user identifier equals a known character string;

(b) determining if a prefix portion of the inner user identifier equals a known character string;

(c) determining if a suffix portion of the inner user identifier equals a known character string; and

(d) determining if the inner user identifier contains a characters in a defined set of characters.

13. The method ofclaim 8, wherein a client comprises a cellular telephone, a smart phone, a laptop computer, or a personal data assistant.

14. In a communications network using an authentication protocol, a method for a routing a client access request to a home authentication server for inner user authentication, comprising:

(a) establishing a secure communication tunnel between a visited server and the client using a roaming identifier for the client;

(b) receiving an access request from the client at the visited server within said secure communication tunnel;

(c) routing the access request to a first home authentication server based on said roaming identifier;

(d) receiving the access request said first home authentication server;

(c) evaluating attributes received in said access request, including an inner user identifier, at said first home authentication server against a local policy; and

(d) routing said access request to a second home authentication server based at least in part on the evaluation of attributes received in said access request against said local policy.

Images