the following detailed description of embodiments of the principles of the invention refers to the accompanying drawings . the same reference numbers in different drawings may identify the same or similar elements . also , the following detailed description does not limit the invention . instead , the scope of the invention is defined by the appended claims and equivalents . systems and methods consistent with the principles of the invention may provide authentication services that permit any associated extensible authentication protocol ( eap )- supported authentication server in a network to accept an eap - formatted message ( hereinafter , “ eap message ”) at any point in an ongoing eap session that is terminated at the other end by a user device . the accepted eap message may then be forwarded to an eap “ state ” service that maintains a state of the eap conversation . the eap state service may formulate an information message based on the state and send the information message to the forwarding eap authentication server . the forwarding eap authentication server may generate an eap request based on the information message which is sent to the user device via the network through a network access device . fig1 illustrates an exemplary network 100 in which systems and methods consistent with the principles of the invention may be implemented . as illustrated , exemplary network 100 may include a user device 110 that operatively connects with a public network 120 which may have an associated network access device 130 . exemplary network 100 may also include authentication servers 140 a and 140 b ( collectively , authentication servers 140 ) that operatively connect to network access device 130 via network 120 . exemplary network 100 may also include a state server 150 that operatively connects to authentication servers 140 . exemplary network 100 may also include an enterprise network 125 that operatively connects to authentication servers 140 . enterprise network 125 may include authentication servers 145 a and 145 b ( collectively , authentication servers 145 ). the number and type of devices illustrated in fig1 are provided for simplicity . in practice , a typical network in which the invention may be implemented could include more or fewer devices and / or networks than what is illustrated in fig1 . in addition , devices depicted as single entities may be implemented in a distributed arrangement . in one implementation consistent with principles of the invention , user device 110 may include any client or host device capable of interacting with networked devices via a unique network identifier , such as a network address , for example , in a distributed environment . user device 110 may include one or more devices , such as a personal computer , a laptop , a personal digital assistant ( pda ), or another type of computation or communication device capable of initiating , processing , transmitting , and / or receiving data and / or voice communications or other media via network 120 . according to one implementation , user device 110 may be a remote user of enterprise network 125 . in one implementation , public network 120 may include a local area network ( lan ), a wide area network ( wan ), a public switched telephone network ( pstn ), an intranet , the internet , or a combination of similar or dissimilar networks . public network 120 may include one or more network devices , such as a network access device 130 ( e . g ., a network access server ( nas )) and / or systems cooperatively operating to receive , send , and / or transport data or other media . according to one implementation , user device 110 may be operated by a user to gain access to public network 120 using a link and network access device 130 . a link may include , for example , a broadband connection , such as a digital subscriber line ( dsl ) connection provided over , for example , shielded twisted pair , a cable modem connection provided over , for example , coaxial cable and / or optical fiber , and / or a wireless connection provided over , for example , a wireless fidelity ( wi - fi ) link and / or free - space optical link . network access device 130 may include one or more devices that provide user device 110 with access to public network 120 and / or enterprise network 125 . for example , network access device 130 may include a router , a network switch , an nas , a firewall , a database , a gateway , a server , a network operations center ( noc ), a translator , a certification authority , etc . in one implementation , network access device 130 , as will be described in greater detail below , may authenticate a user associated with user device 110 in cooperation with authentication servers 140 and 145 , and state server 150 . authentication servers 140 and 145 may include one or more devices for authenticating user device 110 . authentication servers 140 and 145 may negotiate an eap authentication type , and / or authenticate user device 110 . in one implementation , authentication servers 140 may authenticate a user &# 39 ; s access to public network 120 and authentication servers 145 may authenticate a user &# 39 ; s access to enterprise network 125 . authentication servers 140 and 145 may be associated with one or more databases that store authentication information , such as , for example , user identifiers ( ids ) and passwords . in one implementation consistent with principles of the invention , authentication server 140 a may act as an intermediary between public network 120 and enterprise network 125 . for example , authentication server 140 a may operatively function as both a client and a server for purposes of processing various network requests on behalf of user device 110 . according to one implementation , authentication server 140 a may include interpreting functionality , capable of rewriting a request message before forwarding the message to another device . authentication server 140 a may also include caching , administrative control ( e . g ., filtering ), and / or security ( e . g ., firewall ) functionality . enterprise network 125 may include a privately owned and possibly maintained network . for example , enterprise network 125 may include a company &# 39 ; s private network . state server 150 may include one or more devices for maintaining eap session state information . state server 150 may connect to authentication servers 140 / 145 via any well - known technique , such as wired , wireless , and / or optical communications . in one implementation , state server 150 may communicate with authentication servers 140 / 145 using the transmission control protocol ( tcp ), for example , to communicate information messages of the eap session . while state server 150 and authentication servers 140 / 145 are shown as separate devices in fig1 , it will be appreciated that in other implementations , state server 150 and one or more authentication servers 140 / 145 may be implemented as a single device . according to one implementation consistent with the principles of the invention , state server 150 may maintain or have access to information regarding specific types of eap supported by respective authentication servers 140 and 145 . state server 150 may be configured to implement any or all of the supported types of eap . state server 150 may include encryption / decryption functionality . fig2 illustrates an exemplary configuration of state server 150 in an implementation consistent with the principles of the invention . other configurations may alternatively be used . user device 110 , network access device 130 , and authentication servers 140 and 145 may be similarly configured . as illustrated , state server 150 may include a bus 210 , a processor 220 , a memory 230 , a read only memory ( rom ) 240 , a storage device 250 , an input device 260 , an output device 270 , and a communication interface 280 . bus 210 permits communication among components of state server 150 . processor 220 may include any type of conventional processor , microprocessor , or processing logic that interprets and executes instructions . memory 230 may include a random access memory ( ram ) or another type of dynamic storage device that may store information and instructions for execution by processor 220 . memory 230 may also be used to store temporary variables or other intermediate information during execution of instructions by processor 220 . rom 240 may include a conventional rom device and / or another type of static storage device that may store static information and instructions for processor 220 . storage device 250 may include a magnetic disk or optical disk and its corresponding drive and / or some other type of magnetic or optical recording medium and its corresponding drive for storing information and instructions . input device 260 may include one or more conventional mechanisms that permit an operator to input information to state server 150 , such as a keyboard , a mouse , a pen , voice recognition and / or biometric mechanisms , etc . output device 270 may include one or more conventional mechanisms that output information to the operator , including a display , a printer , one or more speakers , etc . communication interface 280 may include any transceiver - like mechanism that enables state server 150 to communicate with other devices and / or systems . for example , communication interface 280 may include a modem or an ethernet interface to a lan . alternatively , communication interface 280 may include other mechanisms for communicating via a network . as used herein , eap may include any variant of eap , e . g ., message digest ( md ) 5 - challenge , protected eap ( peap ), eap - transport layer security ( eap - tls ), eap - tunneled tls ( eap - ttls ), lightweight eap ( leap ), and the like . authentication may be accomplished through the presentation of valid authentication information for a user device , such as a valid identity ( id ) and password . assume , for explanatory purposes , that during a link establishment phase occurring between user device 110 and network access device 130 , an authentication - protocol configuration option may be selected , in which case , network access device 130 communicates a need for eap authentication for user device 110 ( i . e ., the authenticatee ) to authentication server 140 a ( i . e ., the authenticator ). authentication server 140 a formulates one or more requests that are sent to network access device 130 . the request may include a state attribute that identifies authentication server 140 a . the request may also include a request to identify user device 110 . in those situations in which the identity of user device 110 can be determined independently , for example , by the port to which user device 110 is connected ( e . g ., leased lines , dedicated switch , or dial - up ports , etc . ), or other technique ( e . g ., media access control ( mac ) address , etc . ), the request to identify user device 110 may not be included . a challenge may also include information identifying the type of eap authentication , e . g ., eap - tls , peap , leap , etc , to be used . network access device 130 forwards the request to user device 110 and receives a response in reply , which is then forwarded , based on the state attribute , to authentication server 140 a . authentication server 140 a may send a subsequent request , as appropriate . the exchange of requests and responses may continue as long as is necessary to select an appropriate eap authentication protocol to be used for subsequently authenticating user device 110 . alternatively , the request may be dropped if the negotiation of the type of eap to be used in authentication is unsuccessful . fig3 is a flowchart of exemplary processing for authenticating user device 110 according to an implementation consistent with principles of the invention . upon successful negotiation of the type of eap authentication to be used in authenticating user device 110 , as discussed above , an authentication phase 300 begins , in which authentication server 140 a forwards the received opening eap message and / or a data message ( e . g ., using tcp ) relating to the opening eap message that includes at least some of the information communicated during negotiation of the type of eap to be used ( e . g ., eap type , user device identification information , etc . ), to state server 150 , to thereby track an eap session for user device 110 ( operation 310 ). it will be appreciated that in the following discussion of the eap session , that the contents of the eap messages are specific to the type of eap used in the eap session , and thus the eap messages themselves may include information consistent with any of the known eap types , which is not discussed in detail herein . for purposes of some implementations consistent with the principles of the invention , the eap session may involve a multi - step message exchange . the information included in the eap messages in the exchange may not specify the particular authentication server 140 a / 140 b that forwarded the opening eap message . however , it should be understood that for eap sessions in which an eap type is used for which only one eap exchange is necessary ( e . g ., md5 - challenge , one - time passwords , etc . ), or in other cases in which maintaining state information is not desired , state server 150 may be passively involved in the eap authentication . state server 150 may store the forwarded eap message and / or data message and / or information regarding the eap message as state information ( e . g ., message contents , sequential numbering of message , etc .). in situations in which the forwarded eap message is encrypted , state server 150 may in some implementations consistent with the principles of the invention , decrypt the eap message and forward the decrypted message back to authentication server 140 a . state server 150 may generate a request based on the decrypted eap message , for example , based on authentication information for user device 110 . state server 150 may obtain the authentication information from communications with an authenticating authority ( not shown ) any time before or during the eap session , which may then be stored by state server 150 . for example , the authenticating authority may be a third - party certificate authority that issues digital certificates , and the like , to create digital certificates and public - private key pairs , etc . as another example , the authenticating authority may be a third - party entity having associated token cards . state server 150 may formulate an information message and send the information message to authentication server 140 a for generating an eap request ( operation 320 ), for example . authentication server 140 a may receive the information message from state server 150 , generate an eap request , and forward the eap request to network access device 130 ( operation 330 ). the eap request may not include information identifying authentication server 140 a as the source of the eap request . network access device 130 may forward the eap request to user device 110 . user device 110 may send an eap response in reply to the eap request to network access device 130 . since the eap request did not receive information identifying authentication server 140 a , the eap response received by network access device 130 will not identify authentication server 140 a as the intended recipient of the eap response . in the absence of such routing information , network access device 130 may varyingly send the eap response to either of the authentication servers 140 . should authentication server 140 b receive the eap response , it may forward the eap response and / or a data message relating to the eap response to state server 150 ( as opposed to simply dropping the eap response as a result of not having been privy to the ongoing eap session initiated by authentication server 140 a ). should authentication server 140 a receive the eap response , it may likewise forward the eap response and / or a data message relating to the eap response to state server 150 . in either event , state server 150 may receive the eap response and / or the data message regarding the eap response from user device 110 ( operation 340 ). state server 150 may store the forwarded eap response and / or the data message and / or information regarding the eap message , the previously received eap message , the transmitted eap request , and / or the state information , based on the type of eap being used in the eap session . state server 150 may store the information as updated state information for the ongoing eap session . state server 150 may generate a follow - up information message to the eap response based on the eap response contents , the updated state information , the previously received eap message , authentication information for user device 110 , or on any combination thereof . state server 150 may send the follow - up information message , for example , as a follow - up eap request , to whichever of authentication server 140 a or 140 b forwarded the eap response and / or data message ( operation 350 ). again , based on the type of eap being used in the eap session , state server 150 , authentication servers 140 , or both , may determine authentication success or failure based on the forwarded eap response , the previously received eap message , the transmitted eap request , and / or the stored state information ( operation 370 ). authentication server 140 a or 140 b , as appropriate , may receive the follow - up information message from state server 150 , and generate a follow - up eap request based on the follow - up information and the type of eap being used in the eap session . authentication server 140 a or 140 b may send the follow - up eap request to network access device 130 . again , the follow - up eap request may not identify which of authentication servers 140 transmitted the follow - up eap request . network access device 130 may forward the follow - up eap request to user device 110 which may cause another eap response to be sent to authentication servers 140 ( operation 380 ). the above authentication process , i . e ., operations 310 - 380 , may continue with any desired number of successive eap message exchanges , based on the type of eap being used in the eap session , and may involve an equal number of ( or fewer ) authentication servers 140 . in this manner , and consistent with the principles of the invention , state server 150 keeps track of the state of the eap session . the eap authentication session may close when authentication of user device 110 either fails or succeeds , based on the type of eap being used in the eap session , as indicated in an final result message sent from state server 150 to authentication servers 140 and to network access device 130 ( operation 390 ). according to one implementation , state server 150 may be configured to provide the above - described authentication services ( or other services ) to more than one eap session concurrently . according to another implementation consistent with principles of the invention , user device 110 may be a remote user requesting access to enterprise network 125 . authentication of user device 110 as a remote user may be accomplished substantially as discussed above , with the following variation . other variations are possible . authentication servers 145 ( e . g ., customer - hosted authentication servers ) may operatively authenticate user device 110 in those situations in which user device 110 desires access to access - limited resources of public network 120 . accordingly , authentication server 140 a may function substantially as a “ pass - through ” or proxy server , through which the eap messages ( e . g ., responses and requests ) are conveyed . according to one implementation , state server 150 may store information regarding which of authentication servers 145 are responsible for terminating the eap session , for example , from stored information regarding a previously established connection for user device 110 to enterprise network 125 via public network 120 . state server 150 may thus communicate to authentication server 140 a , for example , which of authentication servers 145 initiated the negotiation of the eap authentication type . according to one implementation consistent with principles of the invention , state server 150 may be configured to “ listen ” on a network port for data messages received by authentication servers 140 . state server 150 may listen on the port for tcp connections , for example . authentication servers 140 may respectively connect to the port and then send a message to state server 150 requesting connectivity . state server 150 may reply to the appropriate authentication server 140 to track the eap session . according to another exemplary implementation for providing authentication service , exemplary network 100 may include an additional one , two , three , or more state servers ( not shown ) that may be configured to associate with and function substantially similar to state server 150 ( e . g ., operate in a back - up , fail - safe , and / or redundant configuration ). in one implementation , state server 150 may provide state information to the associated state server ( s ). in another implementation , authentication servers 140 and / or the associated state server ( s ) may be configured to determine an availability — or unavailability — of state server 150 to receive eap messages . for example , a specific state server 150 ( from a group of associated state servers 150 ) for communicating an eap message may be determined from information in the state attribute of the packet containing the eap message . in which case , if the identified state server 150 is unavailable , the eap session may be closed . if , however , the eap message does not specify a specific state server 150 , authentication servers 140 may select any specific state server 150 from among the associated state servers 150 for receipt of the eap message . the state server 150 selection process may be repeated as many times as necessary to find an available state server 150 . accordingly , authentication services functionality may be transferred among one or more associated state servers , for example , any time before and / or during an eap session . according to one implementation , state server 150 may be configured to include a “ session timeout .” for example , each eap session managed by state server 150 may be maintained for a limited time ( e . g ., two minutes ), for example , as specified in the eap message . after which time , state server 150 may delete the state information for the eap session , and any subsequent eap messages for the “ timed - out ” eap session may be returned with status of “ reject .” implementations consistent with principles of the invention provide for enhanced eap authentication by maintaining state information for an eap session . implementations may provide a centralized eap management point in a network to thereby advantageously obviate the need to modify existing network elements ( e . g ., network access servers , etc .) to resolve routing issues in networks in which more than one authentication server is present . accordingly , eap authenticator systems consistent with principles of the invention provide substantially improved authentication over typical authentication processes . the foregoing description of exemplary embodiments of the invention provides illustration and description , but is not intended to be exhaustive or to limit the invention to the precise form disclosed . modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention . for example , while a series of operations has been disclosed with regard to fig3 , the order of the operations may be varied in other implementations consistent with principles of the invention . furthermore , non - dependent operations may be implemented in parallel . it will also be apparent to one of ordinary skill in the art that aspects of the invention , as described above , may be implemented in many different forms of software , firmware , and hardware in the implementations illustrated in the figures . the actual software code or specialized control hardware used to implement aspects consistent with the principles of the invention is not limiting of the invention . thus , the operation and behavior of the aspects of the invention were described without reference to the specific software code — it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein . further , certain portions of the invention may be implemented as “ logic ” that performs one or more functions . such logic may include hardware , such as an application specific integrated circuit ( asic ) or a field programmable gate array , software , or a combination of hardware and software . while aspects have been described in terms of processing messages or packets , such aspects may operate upon any type or form of data , including packet data and non - packet data . the term “ data unit ” may refer to packet or non - packet data . no element , operation , or instruction used in description of the present invention should be construed as critical or essential to the invention unless explicitly described as such . also , as used herein , the article “ a ” is intended to include one or more items . where only one item is intended , the term “ one ” or similar language is used . further , the phrase “ based on ” is intended to mean “ based , at least in part , on ” unless explicitly stated otherwise . the scope of the invention is defined by the claims and their equivalents .