WO2007056313A2 - Allowing network access for proxy mobile ip cases for nodes that do not support chap authentication - Google Patents
Allowing network access for proxy mobile ip cases for nodes that do not support chap authentication Download PDFInfo
- Publication number
- WO2007056313A2 WO2007056313A2 PCT/US2006/043237 US2006043237W WO2007056313A2 WO 2007056313 A2 WO2007056313 A2 WO 2007056313A2 US 2006043237 W US2006043237 W US 2006043237W WO 2007056313 A2 WO2007056313 A2 WO 2007056313A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- chap
- mobile
- response
- pdsn
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/005—Data network PoA devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/18—Service support devices; Network management devices
- H04W88/182—Network node acting on behalf of an other network entity, e.g. proxy
Definitions
- the present invention relates to Mobile IP network technology. More particularly, the present invention relates to supporting proxy Mobile IP registration for nodes that do not support the Challenge Handshake Authentication Protocol (CHAP).
- Mobile IP is a protocol which allows laptop computers or other mobile computer units (referred to as "Mobile Nodes" herein) to roam between various subnetworks at various locations — while maintaining internet and/or WAN connectivity. Without Mobile IP or a related protocol, a Mobile Node would be unable to stay connected while roaming through various sub-networks. This is because the IP address required for any node to communicate over the internet is location specific. Each IP address has a field that specifies the particular sub-network on which the node resides.
- a Mobile IP environment 2 includes the internet (or a WAN) 4 over which a Mobile Node 6 can communicate remotely via mediation by a Home Agent 8 and may also include a Foreign Agent 10.
- the Foreign Agent is implemented in what is generally referred to as a Packet Data Serving Node (PDSN).
- PDSN Packet Data Serving Node
- the Mobile Node 6 can obtain a topologically correct IP address (i.e., collocated IP address) and register this IP address with the Home Agent.
- the Home Agent and Foreign Agent are routers or other network connection devices performing appropriate Mobile IP functions as implemented by software, hardware, and/or firmware.
- a particular Mobile Node e.g., a laptop computer
- the Mobile Node When the Mobile Node roams, it communicates via the internet through an available Foreign Agent.
- Mobile Node 6 normally resides on (or is "based at") a network segment 12 which allows its network entities to communicate over the internet 4 through Home Agent 8 (an appropriately configured router denoted R2).
- Home Agent 8 need not directly connect to the internet.
- it may be connected through another router (a router Rl in this case).
- Router Rl may, in turn, connect one or more other routers (e.g., a router R3) with the internet.
- Network segment 14 may include various other nodes such as a PC 16.
- the nodes on network segment 14 communicate with the internet through a router which doubles as Foreign Agent 10.
- Mobile Node 6 may identify Foreign Agent 10 through various solicitations and advertisements which form part of the Mobile IP protocol.
- Foreign Agent 10 When Mobile Node 6 engages with network segment 14, Foreign Agent 10 relays a registration request to Home Agent 8 (as indicated by the dotted line "Registration").
- Home Agent 8 As indicated by the dotted line "Registration"
- Foreign Agents may then negotiate the conditions of the Mobile Node's attachment to Foreign Agent 10.
- the attachment may be limited to a period of time, such as two hours.
- Home Agent 8 updates an internal "mobility binding table" which specifies the care-of address (e.g., a collocated care-of address or the Foreign Agent's IP address) in association with the identity of Mobile Node 6.
- the Foreign Agent 10 updates an internal "visitor table" which specifies the Mobile Node address, Home Agent address, etc.
- the Mobile Node's home base IP address associated with segment 12
- the Foreign Agent's IP address associated with segment 14.
- Correspondent Node 18 from its new location. In Mobile IPv4, a message from the Mobile Node is then packetized and forwarded through Foreign Agent 10 over the internet 4 and to Correspondent Node 18 (as indicated by the dotted line "packet from MN") according to a standard internet protocol. If Correspondent Node 18 wishes to send a message to Mobile Node ⁇ whether in reply to a message from the Mobile
- Foreign Agent 10 then strips the encapsulation and forwards the message to Mobile Node 6 on sub-network 14.
- the packet forwarding mechanism implemented by the Home and Foreign Agents is often referred to as "tunneling." In the absence of a Foreign Agent, packets are tunneled directly to the Mobile Node 6 collocated care-of address.
- Proxy mobile IP support i.e., proxy registration
- proxy registration may therefore be performed by a proxy entity other than the node, such as an Access Point, a Foreign Agent, or a Packet Data Serving Node (PDSN) (e.g., in a CDMA2000 network) on behalf of the node.
- PDSN Packet Data Serving Node
- multiple Access Points, Foreign Agents or PDSNs can be placed throughout a facility to give users the ability to roam freely throughout an extended area while maintaining uninterrupted access to all network resources.
- the proxy entity In order to send a registration request on behalf of the node, the proxy entity needs the node's IP address and Home Agent address (i.e., default gateway) in order to compose a registration request packet. In addition, the proxy entity also ascertains the node's sub-network network mask (i.e., netmask) in order to ascertain whether
- Mobile IP proxy services are required. Specifically, when the proxy entity determines from the source address of a data packet and the netmask that the node is located on the subnet identical to the subnet of the proxy entity, no Mobile IP service is required on behalf of the node as shown at block. However, when the proxy entity determines from the source address that the node is not located on the subnet of the proxy entity, proxy Mobile IP service is performed by the proxy entity is performed on behalf of the node.
- the proxy entity acts as a proxy Mobile Node to register a client (i.e., node) with its Home Agent. Specifically, the proxy entity identifies or allocates a Home Agent and sends a registration request to the Home Agent to establish a Mobile IP session on behalf of the client. The client receives packets addressed to its home address throughout the Mobile IP session. In this manner, a node may roam while maintaining connectivity to the network.
- PAP Authentication Protocol
- CHAP CHAP
- EAP Extensible Authentication Protocol
- MS-CHAP Microsoft Challenge Handshake Authentication Protocol
- the Mobile IP protocol operates under the assumption that a CHAP challenge and response are used to authenticate a Mobile Node. In other words, the registration request is required to include the CHAP challenge and response.
- a Mobile Node typically provides a CHAP challenge and response in its Mobile IP registration request.
- the Foreign Agent typically advertises a CHAP challenge in an agent advertisement.
- the Mobile Node composes a Mobile IP registration request, it includes a Mobile-Foreign Challenge Extension (MFCE) including the CHAP challenge and a CHAP response as a Mobile Node-AAA key to be shared between the Mobile Node and a AAA server.
- MFCE Mobile-Foreign Challenge Extension
- the CHAP challenge and response are provided to the AAA server, the AAA server uses this information to authenticate the Mobile Node based upon a shared password associated with the CHAP challenge and response.
- the PDSN does not receive a registration request from the node and therefore does not receive a CHAP challenge and response from the node.
- the node negotiates a Point to Point Protocol (PPP) session using the CHAP protocol
- PPP Point to Point Protocol
- the CHAP challenge and response are received by the PDSN from the node during PPP negotiation.
- the PDSN may generate a registration request on behalf of the node using the CHAP challenge and response received during PPP negotiation.
- PPP Point to Point Protocol
- proxy Mobile IP could be supported for nodes that do not use CHAP.
- Various embodiments of the invention support proxy Mobile IP registration for nodes that do not support CHAP. This is accomplished, in part, through the generation of a CHAP challenge and response by either a AAA server or an entity such as a PDSN or Foreign Agent. In this manner, the PDSN or Foreign Agent may generate a Mobile IP registration request based upon the CHAP challenge and response.
- a AAA server supports authentication, authorization, and accounting. While authentication determines "who" an entity is, authorization determines what services a user is allowed to perform, or access.
- a class of servers known as "AAA" or triple-A servers may be employed.
- Various protocols such as the Remote Authentication Dial In User Service (RADIUS) and TACACS+ may be implemented to provide such a server.
- RADIUS Remote Authentication Dial In User Service
- TACACS+ may be implemented to provide such a server.
- RFC 2138 describes the RADIUS Protocol and is hereby incorporated by reference.
- RFC 1492 describes TACACS and the Internet- Draft "The TACACS+ Protocol Version 1.78," available at http://www.ietf.org/internet-drafts/draft-grant-tacacs-02.txt, describes TACACS+. Both of these documents are incorporated herein by reference for all purposes.
- the AAA server generates the CHAP challenge and response, which is subsequently provided to the PDSN or Foreign Agent. Specifically, when the AAA server receives a request message (e.g., authentication request) that identifies a node, it obtains a password associated with the node (e.g., from a node profile maintained by the AAA server). The AAA server generates a CHAP challenge, which may be generated randomly or through other suitable mechanism. The AAA server generates a CHAP response from the password and the CHAP challenge.
- a request message e.g., authentication request
- a password associated with the node e.g., from a node profile maintained by the AAA server.
- the AAA server generates a CHAP challenge, which may be generated randomly or through other suitable mechanism.
- the AAA server generates a CHAP response from the password and the CHAP challenge.
- the AAA server then sends a reply message (e.g., authentication reply) indicating the CHAP challenge and the CHAP response to the PDSN (or Foreign Agent), thereby enabling the PDSN (or Foreign Agent) to generate a Mobile IP registration request based upon the CHAP challenge and response received in the reply message.
- a reply message e.g., authentication reply
- a PDSN or Foreign Agent when a PDSN or Foreign Agent sends a request message identifying a node to a AAA server, it subsequently receives a reply message indicating a CHAP challenge and response.
- the PDSN obtains the CHAP challenge and response from the reply message.
- the PDSN (or Foreign Agent) then composes a Mobile IP registration request message based upon the CHAP challenge and response.
- the AAA server is a single entity. However, in other embodiments, two AAA servers may function to generate the CHAP challenge and response, as well as provide the CHAP challenge and response to the PDSN or Foreign Agent. Specifically, a Local AAA (LAAA) server in the foreign network and a Home AAA (HAAA) server in the home network may be implemented. This enables the LAAA server to contact the HAAA server when it cannot authenticate the node. In accordance with another aspect of the invention, the PDSN or Foreign
- the PDSN (or Foreign Agent) sends a request message (e.g., authentication request) to a AAA server, and receives a reply message (e.g., authentication reply) from the AAA server.
- the reply message includes a password (e.g., associated with the node).
- the AAA server obtains the password from the reply message, it generates a CHAP challenge.
- the PDSN or Foreign Agent
- the PDSN may then generate a CHAP response from the CHAP challenge and password.
- the PDSN or Foreign Agent then composes a Mobile IP registration request message based upon the CHAP challenge and response.
- the AAA server receives a request message identifying a node, it obtains a password associated with the node (e.g., from a node profile maintained by the AAA server).
- the AAA server then sends a reply message to the PDSN or Foreign Agent, thereby enabling the PDSN (or Foreign Agent) to generate a CHAP response using the password for use in generating a Mobile IP registration request including a CHAP challenge generated by the PDSN (or Foreign Agent) and the CHAP response.
- the invention pertains to a system operable to perform and/or initiate any of the disclosed methods in a AAA server or a proxy entity such as a PDSN, Foreign Agent, or Access Point.
- the system includes one or more processors and one or more memories. At least one of the memories and processors are adapted to provide at least some of the above described method operations.
- the invention pertains to a computer program product for performing the disclosed methods.
- the computer program product has at least one computer readable medium and computer program instructions stored within at least one of the computer readable product configured to perform at least some of the above described method operations.
- FIG. l is a diagram of a Mobile IP network segment and associated environment.
- FIG. 2 is a diagram illustrating an exemplary system in which proxy Mobile IP may be implemented by one or more PDSNs.
- FIG. 3 is a transaction flow diagram illustrating a method of performing proxy
- FIG. 4 is a transaction flow diagram illustrating a method of performing proxy Mobile IP registration by a PDSN using a CHAP challenge and response generated by a AAA server in accordance with a first embodiment of the invention.
- FIG. 5 is a transaction flow diagram illustrating a method of performing proxy
- FIG. 6 is a diagrammatic representation of a router in which embodiments of the present invention may be implemented.
- the disclosed embodiments support proxy Mobile IP registration for nodes that do not use CHAP. As will be described in further detail below, this may be accomplished through the generation of a CHAP challenge and response by a AAA server as set forth with reference to FIG. 4 or by an entity such as a PDSN as set forth with reference to FIG. 5. Once the CHAP challenge and response have been generated, the PDSN may generate a Mobile IP registration request based upon the CHAP challenge and response.
- FIG. 2 is a block diagram illustrating a system in which the present invention may be implemented.
- 3GPP2 Third Generation Partnership Project 2
- An exemplary 3GPP2 architecture is described in IS-835 D, available at http://www.3 gpp2.org/Public html/Misc/v&vindex.cfm. entitled "X.P0011-00x-D - cdma2000 Wireless IP Standard (6 DOCUMENTS: -QOl thru -006)," which is incorporated herein by reference for all purposes.
- a Packet Data Serving Node serves as an access router in a 3GPP2/CDMA2000 network.
- the present invention is described as being implemented in a CDMA2000 network, the present invention may also be implemented in another type of Mobile IP network.
- those functions described below as being performed by a PDSN may also be performed by an entity such as a Foreign Agent or Access Point.
- a node 206 may wish to roam from its Home Agent 200 to a first PDSN/Foreign Agent 202. Similarly, once attached to the first PDSN 202, the node 206 may again wish to roam to a second PDSN/Foreign Agent 204.
- the node 206 may have an assigned IP address, when the node 206 roams, it is preferable for the node to maintain this assigned IP address.
- a DHCP server 208 typically dynamically assigns a new IP address to a node when its location within a network has changed, it is preferable to maintain the IP address originally assigned to the node by the DHCP server 208.
- a Packet Control Function (PCF) 210 and Packet Control Function (PCF) 212 are coupled to the PDSNs 202 and 204, respectively.
- the PCFs 210, 212 are typically coupled to a Base Station Control (BSC) (not shown) and Mobile Switching Center (MSC) (not shown).
- BSC Base Station Control
- MSC Mobile Switching Center
- a mobile node implementing Mobile IP registers and de-registers with its Home Agent through the registration process.
- registration is initiated by another network device such as a PDSN on behalf of the node.
- de- registration may be initiated by the PDSN on behalf of the roaming node.
- node 206 that has roamed to the first PDSN 202 is registered with the node's Home Agent 200 when the first PDSN 206 composes and sends a registration request packet via the first PDSN 202.
- the first Foreign Agent's visitor table and the Home Agent's mobility binding table are updated to indicate that the node has roamed to the first Foreign Agent 202.
- the node 206 may be de-registered (e.g., by one of the PDSNs 210, 212, either of the Foreign Agents 202, 204 or the Home Agent 200).
- the first Foreign Agent 202 updates its visitor table to reflect the movement of the node 206.
- the Home Agent's mobility binding table is updated to reflect the movement of the node 206 to the second Foreign Agent 204.
- the appropriate entry in the first Foreign Agent's visitor table and the Home Agent's mobility binding table may be deleted.
- a new entry is then entered in the Home Agent's mobility binding table and the second Foreign Agent's visitor table upon completion of registration of the node with the Home Agent.
- the visitor table may be maintained and updated by the PDSN.
- the Home Agent 200 may authenticate the node by contacting a Home AAA server (HAAA) 214 located in the home network.
- HAAA Home AAA server
- the first PDSN/FA 202 may authenticate the node via a first Local AAA server (LAAAl) 216 located in the local network associated with the first PDSN/FA 202
- the second PDSN/FA 204 may authenticate the node via a second Local AAA server (LAAA2) 218.
- LAAA2 Local AAA server
- FIG. 3 is a transaction flow diagram illustrating a method of performing proxy Mobile IP registration in a CDMA2000 network for nodes that support CHAP.
- Processes performed by a node that does not support Mobile IP, a Packet Control Function (PCF), a PDSN, a Local AAA (LAAA) server located in the foreign network in which the PDSN is located, a Home AAA (HAAA) server located in the home network, and a Home Agent (HA) are represented by vertical lines 302, 304, 306, 308, 310, and 312, respectively.
- the PCF When a data call is set up between the node and PCF at 314, the PCF sends a registration request (RRQ) to the PDSN at 316. Assuming that the call is successful, the PDSN sends a registration reply (RRP) to the PCF at 318.
- the node engages in PPP negotiation using the CHAP protocol at 320, enabling the PDSN to obtain the CHAP challenge and response from the node.
- the PDSN sends an authentication request (e.g., RADIUS access request) to a AAA server for PPP authentication, and in reply receives an authentication response (e.g., RADIUS access response) from the AAA server authenticating the user as a proxy Mobile IP user.
- the PDSN typically sends an authentication request to a LAAA as shown at 322, which may be forwarded to a HAAA server at 324 if the LAAA server cannot authenticate the node.
- the HAAA server sends an authentication response to the LAAA server at 326, which is forwarded to the PDSN at 328.
- the PDSN composes a Mobile IP registration request on behalf of the node at 330 using the PPP challenge and response obtained during PPP negotiation and sends the registration request to the Home Agent at 332.
- the Home Agent In order to authenticate the registration request, the Home Agent typically sends an authentication request to the HAAA server at 334, which authenticates the Mobile IP registration request and sends an authentication response at 336 to the Home Agent.
- the Home Agent processes the registration request and upon receiving the authentication response sends a Mobile IP registration reply to the PDSN at 338.
- a tunnel is then established between the Home Agent and the PDSN at 340.
- a tunnel is also established between the PDSN and the node.
- Authentication requests and responses are sent to a AAA server in a AAA format. As shown in FIG. 3, authentication requests and responses may include RADIUS access requests and responses.
- proxy Mobile IP is unsupported for nodes that do not perform PPP negotiation using the CHAP protocol.
- One alternative for authenticating a node that does not use CHAP during PPP negotiation is to statically configure a shared password at the PDSN and a node that does not support Mobile IP, enabling the password to be used to authenticate the node.
- storing such passwords at a foreign entity such as the PDSN is a security violation, and would compromise the security of the system.
- various embodiments of the invention support proxy Mobile IP registration for nodes that do not support CHAP.
- nodes may perform PPP negotiation using the PAP or EAP protocol.
- a CHAP challenge and response are generated by either a AAA server or PDSN. Once the PDSN obtains this CHAP challenge and response, the PDSN may generate a Mobile IP registration request in accordance with Mobile IP standards requiring that the Mobile IP registration request include the CHAP challenge and response.
- FIG. 4 is a transaction flow diagram illustrating a method of performing proxy
- the PDSN sends a registration reply (RRP) to the PCF at 418.
- RRP registration reply
- the node engages in PPP negotiation using a non-CHAP authentication protocol such as PAP or EAP at 420. Since the PPP negotiation is not performed using CHAP, the PDSN does not receive a CHAP challenge and response during PPP negotiation.
- the PDSN In order to authenticate the node, the PDSN sends an authentication request (e.g., access request) identifying the node to a AAA server, and in reply receives an authentication response (e.g., access response) from the AAA server authenticating the user as a proxy Mobile IP user.
- the PDSN typically sends an authentication request to a LAAA server as shown at 422, which may be forwarded to a HAAA server at 424 if the LAAA server cannot authenticate the node. For instance, this may occur if the LAAA server does not have a node profile for the node.
- a node profile for a node generally includes a password for the node.
- the HAAA server When the authentication request is received, the HAAA server generates a CHAP challenge and response at 426. Specifically, the HAAA server accesses the node's profile to verify that the node is a proxy Mobile IP user. More particularly, in accordance with one embodiment, the HAAA server obtains a password associated with the node from the node's profile. In addition, the HAAA server generates a CHAP challenge. For instance, the CHAP challenge may be generated via a random number generator. The HAAA server then generates a CHAP response from the password and the CHAP challenge. For instance, the CHAP response may be generated by obtaining a hash of the CHAP challenge and the password using a hashing function such as MD-5.
- the HAAA server may also update the node profile to include the CHAP challenge and response.
- the HAAA server generates the CHAP challenge and response.
- a single AAA server e.g., LAAA server
- LAAA server may authenticate a node without contacting another AAA server (e.g., HAAA server).
- the LAAA server or the HAAA server may generate the CHAP challenge and response.
- the HAAA server sends an authentication response to the LAAA server indicating or including the CHAP challenge and response at 428.
- the CHAP challenge and response may be provided in one or more attributes of the authentication response.
- the LAAA server then forwards the authentication response to the PDSN at 430.
- Authentication requests and responses may be transmitted in accordance with a AAA protocol such as RADIUS or TACACS+.
- the authentication requests may be RADIUS access requests and the authentication responses may be RADIUS access responses.
- the PDSN Upon receiving the authentication response, the PDSN obtains the CHAP challenge and response from the authentication response and composes a Mobile IP registration request based upon the CHAP challenge and response on behalf of the node at 432.
- the registration request may include the CHAP challenge and response.
- the Mobile Node when it composes a Mobile IP registration request, it includes a Mobile-Foreign Challenge Extension (MFCE) including the CHAP challenge and the CHAP response as a shared Mobile Node- A AA key.
- MFCE Mobile-Foreign Challenge Extension
- the PDSN then sends the registration request to the Home Agent at 434.
- the Home Agent sends an authentication request to the HAAA server at 436, which authenticates the Mobile IP registration request and sends an authentication response at 438 to the Home Agent.
- the CHAP challenge and response are provided to a AAA server, the AAA server uses this information to authenticate the Mobile Node based upon the shared password associated with the CHAP challenge and response.
- FIG. 5 is a transaction flow diagram illustrating a method of performing proxy
- Steps 414-420 are performed as set forth above with reference to FIG. 4 to establish a PPP session.
- the HAAA server accesses the node's profile to verify that the node is a proxy Mobile IP user. More particularly, the HAAA server obtains the node's password from its node profile at 502. The HAAA server then transmits an authentication response including the node's password to the LAAA server at 504. For instance, the password may be provided in an attribute of the authentication response.
- the LAAA server then forwards the authentication response to the PDSN at 506.
- the HAAA server obtains the node's password from the node profile maintained by the server.
- a single AAA server e.g., LAAA server
- may authenticate a node without contacting another AAA server e.g., HAAA server.
- the LAAA server or the HAAA server may obtain the node's password from its node profile.
- Authentication requests and responses may be transmitted in accordance with a AAA protocol such as RADIUS or TACACS+, as set forth above.
- the PDSN When the authentication response including the password is received by the PDSN, the PDSN generates a CHAP challenge and response at 508. Specifically, the PDSN obtains the password from the authentication response. In addition, the PDSN generates a CHAP challenge. For instance, the CHAP challenge may be generated via a random number generator. The PDSN then generates a CHAP response from the password and the CHAP challenge. For instance, the CHAP response may be generated by obtaining a hash of the CHAP challenge and the password using MD-5. The PDSN then composes a registration request on behalf of the node based upon the CHAP challenge and response generated by the PDSN, and registration of the node with the Home Agent is completed as described above with reference to steps 432-444.
- the above-described embodiments enable proxy Mobile IP registration for nodes that do not support CHAP. This is accomplished through the generation of a CHAP challenge and response by an entity such as a AAA server or PDSN. Once the CHAP challenge and response have been generated, the PDSN may generate a registration request on behalf of the Mobile Node that includes the CHAP challenge and response.
- the invention can also be embodied as computer readable code on a computer readable medium.
- the computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD- ROMs, magnetic tape, and optical data storage devices.
- the apparatus e.g. Mobile Node, Home Agent, Foreign Agent, or PDSN
- the apparatus may be specially constructed for the required purposes, or may be a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory.
- the processes presented herein are not inherently related to any particular router or other apparatus.
- any of the Home Agents of this invention may be specially configured routers such as specially configured router models 1700, 1800, 2500, 2600, 3200, 3600, 4000, 4500, 4700, 7200, and 7500 available from Cisco Systems, Inc. of San Jose, California. A general structure for some of these machines will appear from the description given below.
- the techniques of the present invention may be implemented on software and/or hardware. For example, it can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card.
- the technique of the present invention is implemented in software such as an operating system or in an application running on an operating system.
- a software or software/hardware hybrid system of this invention is preferably implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory.
- Such programmable machine may be a network device designed to handle network traffic.
- Such network devices typically have multiple network interfaces including frame relay, ISDN, and wireless interfaces, for example.
- the roaming systems of this invention may be specially configured routers such as specially configured router models 350, 1100, 1200, 1400, 1600, 2500, 2600, 3200, 3600, 4500, 4700, 7200, 7500, and 12000 available from Cisco Systems, Inc. of San Jose, California. A general architecture for some of these machines will appear from the description given below.
- the registration system may be implemented on a general-purpose network host machine such as a personal computer or workstation.
- the invention may be at least partially implemented on a card (e.g., an interface card) for a network device or a general-purpose computing device.
- a router 1110 suitable for implementing the present invention includes a master central processing unit (CPU) 1162, interfaces 1168, and a bus 1115 (e.g., a PCI bus).
- the CPU 1162 is responsible for such router tasks as routing table computations and network management. It may also be responsible for updating mobility binding and visitor tables, etc. It preferably accomplishes all these functions under the control of software including an operating system (e.g., the Internetwork Operating System (IOS®) of Cisco Systems, Inc.) and any appropriate applications software.
- CPU 1162 may include one or more processors 1163 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors.
- processor 1163 is specially designed hardware for controlling the operations of router 1110.
- a memory 1161 such as non- volatile RAM and/or ROM also forms part of CPU 1162.
- the interfaces 1168 are typically provided as interface cards (sometimes referred to as "line cards"). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the router 1110.
- the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like.
- various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like.
- these interfaces may include ports appropriate for communication with the appropriate media.
- they may also include an independent processor and, in some instances, volatile RAM.
- the independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 1162 to efficiently perform routing computations, network diagnostics, security functions, etc.
- FIG. 6 is one specific router of the present invention, it is by no means the only router architecture on which the present invention can be implemented.
- an architecture having a single processor that handles communications as well as routing computations, etc. is often used.
- other types of interfaces and media could also be used with the router.
- the network device's configuration it may employ one or more memories or memory modules (including memory 1161) configured to store program instructions for the general-purpose network operations and mechanisms for authentication and registration functions described herein.
- the program instructions may control the operation of an operating system and/or one or more applications, for example.
- the memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc.
- the present invention relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein.
- machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM).
- the invention may also be embodied in a computer-readable medium in which a carrier wave travels over an appropriate medium such as airwaves, optical lines, electric lines, etc.
- program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The disclosed embodiments support proxy Mobile IP registration for nodes that do not implement CHAP. This is accomplished, in part, through the generation of a CHAP challenge and response by either a AAA server or a network device such as a PDSN or Foreign Agent. If the CHAP challenge and response is generated by the AAA server, the AAA server provides the CHAP challenge and response to the network device. In this manner, the network device may generate a Mobile IP registration request based upon the CHAP challenge and response.
Description
ALLOWING NETWORK ACCESS FOR PROXY MOBILE IP CASES FOR NODES THAT DO NOT SUPPORT CHAP AUTHENTICATION
RELATED APPLICATIONS This application claims priority from Indian Application No. 2954/DEL/2005, entitled "Allowing Network Access for Proxy Mobile IP Cases for Nodes that Do Not Support CHAP Authentication," by Mukherjee et al, filed in India on November 7, 2005, which is incorporated herein by reference for all purposes.
BACKGROUND OF THE INVENTION
The present invention relates to Mobile IP network technology. More particularly, the present invention relates to supporting proxy Mobile IP registration for nodes that do not support the Challenge Handshake Authentication Protocol (CHAP). Mobile IP is a protocol which allows laptop computers or other mobile computer units (referred to as "Mobile Nodes" herein) to roam between various subnetworks at various locations — while maintaining internet and/or WAN connectivity. Without Mobile IP or a related protocol, a Mobile Node would be unable to stay connected while roaming through various sub-networks. This is because the IP address required for any node to communicate over the internet is location specific. Each IP address has a field that specifies the particular sub-network on which the node resides. If a user desires to take a computer which is normally attached to one sub-network and roam with it so that it passes through different sub-networks, it cannot use its home base IP address. As a result, a business person traveling across the country cannot merely roam with his or her computer across geographically disparate network segments or wireless nodes while remaining connected over the internet. This is not an acceptable state-of-affairs in the age of portable computational devices.
To address this problem, the Mobile IP protocol has been developed and implemented. An implementation of Mobile IP is described in RFC 3344 of the Network Working Group, C. Perkins, Ed., "IP Mobility Support for IPv4," August 2002. Mobile IP is also described in the text "Mobile IP Unplugged" by J. Solomon,
Prentice Hall. Both of these references are incorporated herein by reference in their entireties and for all purposes.
The Mobile IP process in a Mobile IPv4 environment are illustrated in Figure 1. As shown there, a Mobile IP environment 2 includes the internet (or a WAN) 4 over which a Mobile Node 6 can communicate remotely via mediation by a Home Agent 8 and may also include a Foreign Agent 10. In a Third Generation Partnership Project 2 (3GPP2)/CDMA2000 network, the Foreign Agent is implemented in what is generally referred to as a Packet Data Serving Node (PDSN). In the absence of a Foreign Agent in a Mobile IPv4 environment, or in a Mobile IPv6 environment in which a Foreign Agent is not implemented, the Mobile Node 6 can obtain a topologically correct IP address (i.e., collocated IP address) and register this IP address with the Home Agent. (In a Mobile IPv6 environment, this is accomplished via an Access Router rather than a Foreign Agent.) Typically, the Home Agent and Foreign Agent are routers or other network connection devices performing appropriate Mobile IP functions as implemented by software, hardware, and/or firmware. A particular Mobile Node (e.g., a laptop computer) plugged into its home network segment connects with the internet through its designated Home Agent. When the Mobile Node roams, it communicates via the internet through an available Foreign Agent. Presumably, there are many Foreign Agents available at geographically disparate locations to allow wide spread internet connection via the Mobile IP protocol. Note that it is also possible for the Mobile Node to register directly with its Home Agent.
As shown in Figure 1, Mobile Node 6 normally resides on (or is "based at") a network segment 12 which allows its network entities to communicate over the internet 4 through Home Agent 8 (an appropriately configured router denoted R2). Note that Home Agent 8 need not directly connect to the internet. For example, as shown in Figure 1, it may be connected through another router (a router Rl in this case). Router Rl may, in turn, connect one or more other routers (e.g., a router R3) with the internet. Now, suppose that Mobile Node 6 is removed from its home base network segment 12 and roams to a remote network segment 14. Network segment 14 may include various other nodes such as a PC 16. The nodes on network segment 14
communicate with the internet through a router which doubles as Foreign Agent 10. Mobile Node 6 may identify Foreign Agent 10 through various solicitations and advertisements which form part of the Mobile IP protocol. When Mobile Node 6 engages with network segment 14, Foreign Agent 10 relays a registration request to Home Agent 8 (as indicated by the dotted line "Registration"). The Home and
Foreign Agents may then negotiate the conditions of the Mobile Node's attachment to Foreign Agent 10. For example, the attachment may be limited to a period of time, such as two hours. When the negotiation is successfully completed, Home Agent 8 updates an internal "mobility binding table" which specifies the care-of address (e.g., a collocated care-of address or the Foreign Agent's IP address) in association with the identity of Mobile Node 6. Further, the Foreign Agent 10 updates an internal "visitor table" which specifies the Mobile Node address, Home Agent address, etc. In effect, the Mobile Node's home base IP address (associated with segment 12) has been shifted to the Foreign Agent's IP address (associated with segment 14). Now, suppose that Mobile Node 6 wishes to send a message to a
Correspondent Node 18 from its new location. In Mobile IPv4, a message from the Mobile Node is then packetized and forwarded through Foreign Agent 10 over the internet 4 and to Correspondent Node 18 (as indicated by the dotted line "packet from MN") according to a standard internet protocol. If Correspondent Node 18 wishes to send a message to Mobile Node ~ whether in reply to a message from the Mobile
Node or for any other reason ~ it addresses that message to the IP address of Mobile Node 6 on sub-network 12. The packets of that message are then forwarded over the internet 4 and to router Rl and ultimately to Home Agent 8 as indicated by the dotted line ("packet to MN(I)"). From its mobility binding table, Home Agent 8 recognizes that Mobile Node 6 is no longer attached to network segment 12. It then encapsulates the packets from Correspondent Node 18 (which are addressed to Mobile Node 6 on network segment 12) according to a Mobile IP protocol and forwards these encapsulated packets to a "care of address for Mobile Node 6 as shown by the dotted line ("packet to MN(2)"). The care-of address may be, for example, the IP address of Foreign Agent 10. Foreign Agent 10 then strips the encapsulation and forwards the message to Mobile Node 6 on sub-network 14. The packet forwarding mechanism implemented by the Home and Foreign Agents is often referred to as "tunneling." In
the absence of a Foreign Agent, packets are tunneled directly to the Mobile Node 6 collocated care-of address.
Since a node may not support Mobile IP, a node that changes its location within a network cannot initiate registration with its Home Agent. Proxy mobile IP support (i.e., proxy registration) may therefore be performed by a proxy entity other than the node, such as an Access Point, a Foreign Agent, or a Packet Data Serving Node (PDSN) (e.g., in a CDMA2000 network) on behalf of the node. Typically, multiple Access Points, Foreign Agents or PDSNs can be placed throughout a facility to give users the ability to roam freely throughout an extended area while maintaining uninterrupted access to all network resources. Once a node is registered with a Home Agent, packets may be forwarded by the Home Agent to the PDSN or Foreign Agent.
In order to send a registration request on behalf of the node, the proxy entity needs the node's IP address and Home Agent address (i.e., default gateway) in order to compose a registration request packet. In addition, the proxy entity also ascertains the node's sub-network network mask (i.e., netmask) in order to ascertain whether
Mobile IP proxy services are required. Specifically, when the proxy entity determines from the source address of a data packet and the netmask that the node is located on the subnet identical to the subnet of the proxy entity, no Mobile IP service is required on behalf of the node as shown at block. However, when the proxy entity determines from the source address that the node is not located on the subnet of the proxy entity, proxy Mobile IP service is performed by the proxy entity is performed on behalf of the node.
Thus, the proxy entity acts as a proxy Mobile Node to register a client (i.e., node) with its Home Agent. Specifically, the proxy entity identifies or allocates a Home Agent and sends a registration request to the Home Agent to establish a Mobile IP session on behalf of the client. The client receives packets addressed to its home address throughout the Mobile IP session. In this manner, a node may roam while maintaining connectivity to the network.
There are a number of authentication mechanisms that may be used to authenticate a user. These authentication mechanisms include Password
Authentication Protocol (PAP), CHAP, Extensible Authentication Protocol (EAP), and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). However,
the Mobile IP protocol operates under the assumption that a CHAP challenge and response are used to authenticate a Mobile Node. In other words, the registration request is required to include the CHAP challenge and response.
During the Mobile IP registration process, a Mobile Node typically provides a CHAP challenge and response in its Mobile IP registration request. Specifically, the Foreign Agent typically advertises a CHAP challenge in an agent advertisement. When the Mobile Node composes a Mobile IP registration request, it includes a Mobile-Foreign Challenge Extension (MFCE) including the CHAP challenge and a CHAP response as a Mobile Node-AAA key to be shared between the Mobile Node and a AAA server. When the CHAP challenge and response are provided to the AAA server, the AAA server uses this information to authenticate the Mobile Node based upon a shared password associated with the CHAP challenge and response.
In a proxy Mobile IP situation in a network such as a CDMA2000 network, the PDSN does not receive a registration request from the node and therefore does not receive a CHAP challenge and response from the node. However, if the node negotiates a Point to Point Protocol (PPP) session using the CHAP protocol, the CHAP challenge and response are received by the PDSN from the node during PPP negotiation. In these situations, the PDSN may generate a registration request on behalf of the node using the CHAP challenge and response received during PPP negotiation.
Unfortunately, many nodes do not support the CHAP protocol. For example, PAP is often the only supported protocol, since it is an older protocol. Since the PDSN does not receive a CHAP challenge and response during PPP negotiation for these nodes, the PDSN cannot construct a registration request including a CHAP challenge and response. Accordingly, proxy Mobile IP is unsupported in these systems.
In view of the above, it would be beneficial if proxy Mobile IP could be supported for nodes that do not use CHAP.
SUMMARY OF THE INVENTION
Various embodiments of the invention support proxy Mobile IP registration for nodes that do not support CHAP. This is accomplished, in part, through the
generation of a CHAP challenge and response by either a AAA server or an entity such as a PDSN or Foreign Agent. In this manner, the PDSN or Foreign Agent may generate a Mobile IP registration request based upon the CHAP challenge and response. A AAA server supports authentication, authorization, and accounting. While authentication determines "who" an entity is, authorization determines what services a user is allowed to perform, or access. A class of servers known as "AAA" or triple-A servers may be employed. Various protocols such as the Remote Authentication Dial In User Service (RADIUS) and TACACS+ may be implemented to provide such a server. Note that the Home Agent or Foreign Agent providing accounting information to the server must provide communications in formats required by the AAA server protocol. RFC 2138 describes the RADIUS Protocol and is hereby incorporated by reference. Similarly, RFC 1492 describes TACACS and the Internet- Draft "The TACACS+ Protocol Version 1.78," available at http://www.ietf.org/internet-drafts/draft-grant-tacacs-02.txt, describes TACACS+. Both of these documents are incorporated herein by reference for all purposes.
In accordance with one aspect of the invention, the AAA server generates the CHAP challenge and response, which is subsequently provided to the PDSN or Foreign Agent. Specifically, when the AAA server receives a request message (e.g., authentication request) that identifies a node, it obtains a password associated with the node (e.g., from a node profile maintained by the AAA server). The AAA server generates a CHAP challenge, which may be generated randomly or through other suitable mechanism. The AAA server generates a CHAP response from the password and the CHAP challenge. The AAA server then sends a reply message (e.g., authentication reply) indicating the CHAP challenge and the CHAP response to the PDSN (or Foreign Agent), thereby enabling the PDSN (or Foreign Agent) to generate a Mobile IP registration request based upon the CHAP challenge and response received in the reply message.
As set forth above, when a PDSN or Foreign Agent sends a request message identifying a node to a AAA server, it subsequently receives a reply message indicating a CHAP challenge and response. The PDSN obtains the CHAP challenge
and response from the reply message. The PDSN (or Foreign Agent) then composes a Mobile IP registration request message based upon the CHAP challenge and response.
In accordance with one embodiment, the AAA server is a single entity. However, in other embodiments, two AAA servers may function to generate the CHAP challenge and response, as well as provide the CHAP challenge and response to the PDSN or Foreign Agent. Specifically, a Local AAA (LAAA) server in the foreign network and a Home AAA (HAAA) server in the home network may be implemented. This enables the LAAA server to contact the HAAA server when it cannot authenticate the node. In accordance with another aspect of the invention, the PDSN or Foreign
Agent generates the CHAP challenge and response, which it subsequently uses to generate a Mobile IP registration request. Specifically, the PDSN (or Foreign Agent) sends a request message (e.g., authentication request) to a AAA server, and receives a reply message (e.g., authentication reply) from the AAA server. The reply message includes a password (e.g., associated with the node). Once the PDSN (or Foreign
Agent) obtains the password from the reply message, it generates a CHAP challenge. The PDSN (or Foreign Agent) may then generate a CHAP response from the CHAP challenge and password. The PDSN (or Foreign Agent) then composes a Mobile IP registration request message based upon the CHAP challenge and response. As set forth above, when the AAA server receives a request message identifying a node, it obtains a password associated with the node (e.g., from a node profile maintained by the AAA server). The AAA server then sends a reply message to the PDSN or Foreign Agent, thereby enabling the PDSN (or Foreign Agent) to generate a CHAP response using the password for use in generating a Mobile IP registration request including a CHAP challenge generated by the PDSN (or Foreign Agent) and the CHAP response.
In accordance with another aspect of the invention, the invention pertains to a system operable to perform and/or initiate any of the disclosed methods in a AAA server or a proxy entity such as a PDSN, Foreign Agent, or Access Point. The system includes one or more processors and one or more memories. At least one of the memories and processors are adapted to provide at least some of the above described method operations. In yet a further embodiment, the invention pertains to a computer
program product for performing the disclosed methods. The computer program product has at least one computer readable medium and computer program instructions stored within at least one of the computer readable product configured to perform at least some of the above described method operations. These and other features and advantages of the present invention will be presented in more detail in the following specification of the invention and the accompanying figures, which illustrate by way of example the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. l is a diagram of a Mobile IP network segment and associated environment.
FIG. 2 is a diagram illustrating an exemplary system in which proxy Mobile IP may be implemented by one or more PDSNs. FIG. 3 is a transaction flow diagram illustrating a method of performing proxy
Mobile IP registration in a CDMA2000 network for nodes that support CHAP.
FIG. 4 is a transaction flow diagram illustrating a method of performing proxy Mobile IP registration by a PDSN using a CHAP challenge and response generated by a AAA server in accordance with a first embodiment of the invention. FIG. 5 is a transaction flow diagram illustrating a method of performing proxy
Mobile IP registration by a PDSN using a CHAP challenge and response generated by the PDSN in accordance with a second embodiment of the invention.
FIG. 6 is a diagrammatic representation of a router in which embodiments of the present invention may be implemented.
DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
Reference will now be made in detail to a specific embodiment of the invention. An example of this embodiment is illustrated in the accompanying drawings. While the invention will be described in conjunction with this specific embodiment, it will be understood that it is not intended to limit the invention to one embodiment. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined
by the appended claims. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
The disclosed embodiments support proxy Mobile IP registration for nodes that do not use CHAP. As will be described in further detail below, this may be accomplished through the generation of a CHAP challenge and response by a AAA server as set forth with reference to FIG. 4 or by an entity such as a PDSN as set forth with reference to FIG. 5. Once the CHAP challenge and response have been generated, the PDSN may generate a Mobile IP registration request based upon the CHAP challenge and response.
FIG. 2 is a block diagram illustrating a system in which the present invention may be implemented. In the following description, the disclosed embodiments are described with reference to a CDMA2000 network, which is implemented using a Third Generation Partnership Project 2 (3GPP2) architecture. An exemplary 3GPP2 architecture is described in IS-835 D, available at http://www.3 gpp2.org/Public html/Misc/v&vindex.cfm. entitled "X.P0011-00x-D - cdma2000 Wireless IP Standard (6 DOCUMENTS: -QOl thru -006)," which is incorporated herein by reference for all purposes. A Packet Data Serving Node (PDSN) serves as an access router in a 3GPP2/CDMA2000 network. Although the present invention is described as being implemented in a CDMA2000 network, the present invention may also be implemented in another type of Mobile IP network. Thus, those functions described below as being performed by a PDSN may also be performed by an entity such as a Foreign Agent or Access Point.
As shown in FIG. 2, a node 206 may wish to roam from its Home Agent 200 to a first PDSN/Foreign Agent 202. Similarly, once attached to the first PDSN 202, the node 206 may again wish to roam to a second PDSN/Foreign Agent 204. Although the node 206 may have an assigned IP address, when the node 206 roams, it is preferable for the node to maintain this assigned IP address. For instance, although a DHCP server 208 typically dynamically assigns a new IP address to a node when its
location within a network has changed, it is preferable to maintain the IP address originally assigned to the node by the DHCP server 208.
In a CDMA2000 network, a Packet Control Function (PCF) 210 and Packet Control Function (PCF) 212 are coupled to the PDSNs 202 and 204, respectively. The PCFs 210, 212, are typically coupled to a Base Station Control (BSC) (not shown) and Mobile Switching Center (MSC) (not shown). Typically, a mobile node implementing Mobile IP registers and de-registers with its Home Agent through the registration process. However, during proxy registration, registration is initiated by another network device such as a PDSN on behalf of the node. Similarly, de- registration may be initiated by the PDSN on behalf of the roaming node. For instance, node 206 that has roamed to the first PDSN 202 is registered with the node's Home Agent 200 when the first PDSN 206 composes and sends a registration request packet via the first PDSN 202. Thus, the first Foreign Agent's visitor table and the Home Agent's mobility binding table are updated to indicate that the node has roamed to the first Foreign Agent 202. When the node 206 roams to the second PDSN 204, the node 206 may be de-registered (e.g., by one of the PDSNs 210, 212, either of the Foreign Agents 202, 204 or the Home Agent 200). In other words, the first Foreign Agent 202 updates its visitor table to reflect the movement of the node 206. Similarly, the Home Agent's mobility binding table is updated to reflect the movement of the node 206 to the second Foreign Agent 204. Thus, the appropriate entry in the first Foreign Agent's visitor table and the Home Agent's mobility binding table may be deleted. A new entry is then entered in the Home Agent's mobility binding table and the second Foreign Agent's visitor table upon completion of registration of the node with the Home Agent. Alternatively, the visitor table may be maintained and updated by the PDSN.
The Home Agent 200 may authenticate the node by contacting a Home AAA server (HAAA) 214 located in the home network. Similarly, the first PDSN/FA 202 may authenticate the node via a first Local AAA server (LAAAl) 216 located in the local network associated with the first PDSN/FA 202, while the second PDSN/FA 204 may authenticate the node via a second Local AAA server (LAAA2) 218.
Authentication will be described in further detail below with reference to FIGs. 4-5.
Proxy Mobile IP registration is currently supported for nodes that support CHAP. FIG. 3 is a transaction flow diagram illustrating a method of performing proxy Mobile IP registration in a CDMA2000 network for nodes that support CHAP. Processes performed by a node that does not support Mobile IP, a Packet Control Function (PCF), a PDSN, a Local AAA (LAAA) server located in the foreign network in which the PDSN is located, a Home AAA (HAAA) server located in the home network, and a Home Agent (HA) are represented by vertical lines 302, 304, 306, 308, 310, and 312, respectively. When a data call is set up between the node and PCF at 314, the PCF sends a registration request (RRQ) to the PDSN at 316. Assuming that the call is successful, the PDSN sends a registration reply (RRP) to the PCF at 318. The node engages in PPP negotiation using the CHAP protocol at 320, enabling the PDSN to obtain the CHAP challenge and response from the node.
The PDSN sends an authentication request (e.g., RADIUS access request) to a AAA server for PPP authentication, and in reply receives an authentication response (e.g., RADIUS access response) from the AAA server authenticating the user as a proxy Mobile IP user. As shown, the PDSN typically sends an authentication request to a LAAA as shown at 322, which may be forwarded to a HAAA server at 324 if the LAAA server cannot authenticate the node. In these instances, the HAAA server sends an authentication response to the LAAA server at 326, which is forwarded to the PDSN at 328.
The PDSN composes a Mobile IP registration request on behalf of the node at 330 using the PPP challenge and response obtained during PPP negotiation and sends the registration request to the Home Agent at 332. In order to authenticate the registration request, the Home Agent typically sends an authentication request to the HAAA server at 334, which authenticates the Mobile IP registration request and sends an authentication response at 336 to the Home Agent. The Home Agent processes the registration request and upon receiving the authentication response sends a Mobile IP registration reply to the PDSN at 338. A tunnel is then established between the Home Agent and the PDSN at 340. A tunnel is also established between the PDSN and the node.
Authentication requests and responses are sent to a AAA server in a AAA format. As shown in FIG. 3, authentication requests and responses may include RADIUS access requests and responses.
Currently, proxy Mobile IP is unsupported for nodes that do not perform PPP negotiation using the CHAP protocol. One alternative for authenticating a node that does not use CHAP during PPP negotiation is to statically configure a shared password at the PDSN and a node that does not support Mobile IP, enabling the password to be used to authenticate the node. However, storing such passwords at a foreign entity such as the PDSN is a security violation, and would compromise the security of the system.
As will be described in further detail below, various embodiments of the invention support proxy Mobile IP registration for nodes that do not support CHAP. For instance, nodes may perform PPP negotiation using the PAP or EAP protocol. As will be described in further detail below, a CHAP challenge and response are generated by either a AAA server or PDSN. Once the PDSN obtains this CHAP challenge and response, the PDSN may generate a Mobile IP registration request in accordance with Mobile IP standards requiring that the Mobile IP registration request include the CHAP challenge and response.
Generally, in a CDMA network, the Home Agent will access a AAA server to authenticate a node, unless the Home Agent maintains local security associations. In the described embodiments, both a Local AAA (LAAA) server and Home AAA (HAAA) server are illustrated. However, it is important to note that a single AAA server (e.g., LAAA server) may authenticate a node without contacting another AAA server (e.g., HAAA server). FIG. 4 is a transaction flow diagram illustrating a method of performing proxy
Mobile IP registration by a PDSN using a CHAP challenge and response generated by a AAA server in accordance with a first embodiment of the invention. Processes performed by a node that does not support Mobile IP, Packet Control Function (PCF), PDSN, Local AAA (LAAA) server located in the foreign network in which the PDSN is located, Home AAA (HAAA) server located in the home network, and Home Agent (HA) are represented by vertical lines 402, 404, 406, 408, 410, and 412, respectively. When a data call is set up between the node and PCF at 414, the PCF
sends a registration request (RRQ) to the PDSN at 416. Assuming that the call is successful, the PDSN sends a registration reply (RRP) to the PCF at 418. The node engages in PPP negotiation using a non-CHAP authentication protocol such as PAP or EAP at 420. Since the PPP negotiation is not performed using CHAP, the PDSN does not receive a CHAP challenge and response during PPP negotiation.
In order to authenticate the node, the PDSN sends an authentication request (e.g., access request) identifying the node to a AAA server, and in reply receives an authentication response (e.g., access response) from the AAA server authenticating the user as a proxy Mobile IP user. As shown, the PDSN typically sends an authentication request to a LAAA server as shown at 422, which may be forwarded to a HAAA server at 424 if the LAAA server cannot authenticate the node. For instance, this may occur if the LAAA server does not have a node profile for the node. A node profile for a node generally includes a password for the node.
When the authentication request is received, the HAAA server generates a CHAP challenge and response at 426. Specifically, the HAAA server accesses the node's profile to verify that the node is a proxy Mobile IP user. More particularly, in accordance with one embodiment, the HAAA server obtains a password associated with the node from the node's profile. In addition, the HAAA server generates a CHAP challenge. For instance, the CHAP challenge may be generated via a random number generator. The HAAA server then generates a CHAP response from the password and the CHAP challenge. For instance, the CHAP response may be generated by obtaining a hash of the CHAP challenge and the password using a hashing function such as MD-5. The HAAA server may also update the node profile to include the CHAP challenge and response. In this example, the HAAA server generates the CHAP challenge and response. However, it is important to note that a single AAA server (e.g., LAAA server) may authenticate a node without contacting another AAA server (e.g., HAAA server). Thus, either the LAAA server or the HAAA server may generate the CHAP challenge and response. Once the CHAP challenge and response have been generated, the HAAA server sends an authentication response to the LAAA server indicating or including the CHAP challenge and response at 428. For instance, the CHAP challenge and
response may be provided in one or more attributes of the authentication response. The LAAA server then forwards the authentication response to the PDSN at 430. Authentication requests and responses may be transmitted in accordance with a AAA protocol such as RADIUS or TACACS+. For instance, as shown in this example, the authentication requests may be RADIUS access requests and the authentication responses may be RADIUS access responses.
Upon receiving the authentication response, the PDSN obtains the CHAP challenge and response from the authentication response and composes a Mobile IP registration request based upon the CHAP challenge and response on behalf of the node at 432. For instance, the registration request may include the CHAP challenge and response. Specifically, when the Mobile Node composes a Mobile IP registration request, it includes a Mobile-Foreign Challenge Extension (MFCE) including the CHAP challenge and the CHAP response as a shared Mobile Node- A AA key. The PDSN then sends the registration request to the Home Agent at 434. In order to authenticate the registration request, the Home Agent sends an authentication request to the HAAA server at 436, which authenticates the Mobile IP registration request and sends an authentication response at 438 to the Home Agent. Specifically, as described above, when the CHAP challenge and response are provided to a AAA server, the AAA server uses this information to authenticate the Mobile Node based upon the shared password associated with the CHAP challenge and response.
The Home Agent sends a Mobile IP registration reply to the PDSN at 440. A tunnel is then established between the Home Agent and the PDSN at 442. In addition, a tunnel is also established between the PDSN and the node at 444. FIG. 5 is a transaction flow diagram illustrating a method of performing proxy
Mobile IP registration by a PDSN using a CHAP challenge and response generated by the PDSN in accordance with a second embodiment of the invention. Steps 414-420 are performed as set forth above with reference to FIG. 4 to establish a PPP session. When an authentication request identifying a node is transmitted as described above with respect to steps 422-424, the HAAA server accesses the node's profile to verify that the node is a proxy Mobile IP user. More particularly, the HAAA server obtains the node's password from its node profile at 502. The HAAA server then
transmits an authentication response including the node's password to the LAAA server at 504. For instance, the password may be provided in an attribute of the authentication response. The LAAA server then forwards the authentication response to the PDSN at 506. In this example, the HAAA server obtains the node's password from the node profile maintained by the server. However, it is important to note that a single AAA server (e.g., LAAA server) may authenticate a node without contacting another AAA server (e.g., HAAA server). Thus, either the LAAA server or the HAAA server may obtain the node's password from its node profile. Authentication requests and responses may be transmitted in accordance with a AAA protocol such as RADIUS or TACACS+, as set forth above.
When the authentication response including the password is received by the PDSN, the PDSN generates a CHAP challenge and response at 508. Specifically, the PDSN obtains the password from the authentication response. In addition, the PDSN generates a CHAP challenge. For instance, the CHAP challenge may be generated via a random number generator. The PDSN then generates a CHAP response from the password and the CHAP challenge. For instance, the CHAP response may be generated by obtaining a hash of the CHAP challenge and the password using MD-5. The PDSN then composes a registration request on behalf of the node based upon the CHAP challenge and response generated by the PDSN, and registration of the node with the Home Agent is completed as described above with reference to steps 432-444.
The above-described embodiments enable proxy Mobile IP registration for nodes that do not support CHAP. This is accomplished through the generation of a CHAP challenge and response by an entity such as a AAA server or PDSN. Once the CHAP challenge and response have been generated, the PDSN may generate a registration request on behalf of the Mobile Node that includes the CHAP challenge and response.
The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the
computer readable medium include read-only memory, random-access memory, CD- ROMs, magnetic tape, and optical data storage devices.
The apparatus (e.g. Mobile Node, Home Agent, Foreign Agent, or PDSN) of this invention may be specially constructed for the required purposes, or may be a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. The processes presented herein are not inherently related to any particular router or other apparatus. In a preferred embodiment, any of the Home Agents of this invention may be specially configured routers such as specially configured router models 1700, 1800, 2500, 2600, 3200, 3600, 4000, 4500, 4700, 7200, and 7500 available from Cisco Systems, Inc. of San Jose, California. A general structure for some of these machines will appear from the description given below.
Generally, the techniques of the present invention may be implemented on software and/or hardware. For example, it can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card. In a specific embodiment of this invention, the technique of the present invention is implemented in software such as an operating system or in an application running on an operating system. A software or software/hardware hybrid system of this invention is preferably implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. Such programmable machine may be a network device designed to handle network traffic. Such network devices typically have multiple network interfaces including frame relay, ISDN, and wireless interfaces, for example. Specific examples of such network devices include routers and switches. For example, the roaming systems of this invention may be specially configured routers such as specially configured router models 350, 1100, 1200, 1400, 1600, 2500, 2600, 3200, 3600, 4500, 4700, 7200, 7500, and 12000 available from Cisco Systems, Inc. of San Jose, California. A general architecture for some of these machines will appear from the description given below. In an alternative embodiment, the registration system may be implemented on a general-purpose network host machine such as a personal computer or workstation. Further, the
invention may be at least partially implemented on a card (e.g., an interface card) for a network device or a general-purpose computing device.
Referring now to FIG. 6, a router 1110 suitable for implementing the present invention includes a master central processing unit (CPU) 1162, interfaces 1168, and a bus 1115 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 1162 is responsible for such router tasks as routing table computations and network management. It may also be responsible for updating mobility binding and visitor tables, etc. It preferably accomplishes all these functions under the control of software including an operating system (e.g., the Internetwork Operating System (IOS®) of Cisco Systems, Inc.) and any appropriate applications software. CPU 1162 may include one or more processors 1163 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 1163 is specially designed hardware for controlling the operations of router 1110. In a specific embodiment, a memory 1161 (such as non- volatile RAM and/or ROM) also forms part of CPU 1162. However, there are many different ways in which memory could be coupled to the system. The interfaces 1168 are typically provided as interface cards (sometimes referred to as "line cards"). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the router 1110. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 1162 to efficiently perform routing computations, network diagnostics, security functions, etc.
Although the system shown in FIG. 6 is one specific router of the present invention, it is by no means the only router architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the router. Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory 1161) configured to store program instructions for the general-purpose network operations and mechanisms for authentication and registration functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc.
Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). The invention may also be embodied in a computer-readable medium in which a carrier wave travels over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.
Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Moreover, although the example described refers primarily to IPv4, the present invention may be used with other versions of IP. In addition, although the description refers to the implementation of proxy Mobile IP in a PDSN, the disclosed embodiments may also be implemented in a Foreign Agent, Access Point, or other entity. Thus, the disclosed
embodiments need not be performed in a CDMA2000 network. Therefore, the described embodiments should be taken as illustrative and not restrictive, and the invention should not be limited to the details given herein but should be defined by the following claims and their full scope of equivalents.
Claims
1. In a AAA server, a method of authenticating a node, comprising: receiving a request message identifying a node, the request message being in a AAA format; obtaining a password associated with the node; generating a CHAP challenge; generating a CHAP response from the password and the CHAP challenge; and sending a reply message in a AAA format and indicating the CHAP challenge and the CHAP response to a network device, thereby enabling the network device to generate a Mobile IP registration request including the CHAP challenge and CHAP response.
2. The method as recited in claim 1 , further comprising: storing the CHAP challenge and the CHAP response in association with the password.
3. The method as recited in claim 1 , wherein the request message is a RADIUS access request and the reply message is a RADIUS access reply.
4. The method as recited in claim 1, wherein the node does not support the CHAP protocol.
5. The method as recited in claim 1, wherein the node supports the PAP protocol.
6. The method as recited in claim 1, wherein the AAA server is in a local network in which the network device is located.
7. The method as recited in claim 1, wherein the AAA server is in a home network of the node.
8. In a network device, a method of composing a Mobile IP registration request on behalf of a node, comprising: sending a request message identifying a node to a AAA server, the request message being in a AAA format; receiving a reply message in a AAA format and indicating a CHAP challenge and a CHAP response; obtaining the CHAP challenge and the CHAP response from the reply message; and composing the Mobile IP registration request message based upon the CHAP challenge and the CHAP response.
9. The method as recited in claim 8, wherein the request message is a RADIUS access request and the reply message is a RADIUS access reply.
10. The method as recited in claim 8, wherein the node does not support the CHAP protocol.
11. The method as recited in claim 8, wherein the node supports the PAP protocol.
12. The method as recited in claim 8, wherein the AAA server is in a local network in which the network device is located or a home network of the node.
13. The method as recited in claim 8, wherein the reply message includes the CHAP challenge and the CHAP response.
14. In a AAA server, a method of authenticating a node, comprising: receiving a request message identifying a node, the request message being in a
AAA format; obtaining a password associated with the node; and sending a reply message in a AAA format and including the password to a PDSN or Foreign Agent, thereby enabling the PDSN or Foreign Agent to generate a CHAP response using the password for use in generating a Mobile IP registration request including a CHAP challenge generated by the PDSN or Foreign Agent and the CHAP response.
15. The method as recited in claim 14, wherein the request message is a RADIUS access request and the reply message is a RADIUS access reply.
16. The method as recited in claim 14, wherein the node does not support the CHAP protocol.
17. The method as recited in claim 14, wherein the node supports the PAP protocol.
18. The method as recited in claim 14, wherein the AAA server is in a local network in which the PDSN or Foreign Agent is located.
19. The method as recited in claim 14, wherein the AAA server is in a home network of the node.
20. In a network device, a method of composing a Mobile IP registration request on behalf of a node, comprising: sending a request message identifying a node to a AAA server, the request message being in a AAA format; receiving a reply message, the reply message being in a AAA format and including a password; obtaining the password from the reply message; generating a CHAP challenge; generating a CHAP response from the CHAP challenge and the password; and composing the Mobile IP registration request message based upon the CHAP challenge and the CHAP response generated by the network device.
21. The method as recited in claim 20, wherein the request message is a RADIUS access request and the reply message is a RADIUS access reply.
22. The method as recited in claim 20, wherein the node does not support the CHAP protocol.
23. The method as recited in claim 20, wherein the node supports the PAP protocol.
24. The method as recited in claim 20, wherein the AAA server is in a local network in which the network device is located or a home network of the node.
25. A network device adapted for composing a Mobile IP registration request on behalf of a node, comprising: means for sending a request message identifying a node to a AAA server, the request message being in a AAA format; means for receiving a reply message in a AAA format and indicating a CHAP challenge and a CHAP response; means for obtaining the CHAP challenge and the CHAP response from the reply message; and means for composing the Mobile IP registration request message based upon the CHAP challenge and the CHAP response.
26. A network device adapted for composing a Mobile IP registration request on behalf of a node, comprising: a processor; and a memory, at least one of the processor and the memory being adapted for: sending a request message identifying a node to a AAA server, the request message being in a AAA format; receiving a reply message in a AAA format and indicating a CHAP challenge and a CHAP response; obtaining the CHAP challenge and the CHAP response from the reply message; and composing the Mobile IP registration request message based upon the CHAP challenge and the CHAP response.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006800415535A CN101305543B (en) | 2005-11-07 | 2006-11-06 | Method and device for allowing network access for proxy mobile IP cases for nodes that do not support CHAP authentication |
EP06836995.8A EP1946482B1 (en) | 2005-11-07 | 2006-11-06 | Allowing network access for proxy mobile ip cases for nodes that do not support chap authentication |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN2954DE2005 | 2005-11-07 | ||
IN2954/DEL/2005 | 2005-11-07 | ||
US11/316,098 US8042154B2 (en) | 2005-11-07 | 2005-12-21 | Allowing network access for proxy mobile IP cases for nodes that do not support CHAP authentication |
US11/316,098 | 2005-12-21 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2007056313A2 true WO2007056313A2 (en) | 2007-05-18 |
WO2007056313A3 WO2007056313A3 (en) | 2007-07-05 |
Family
ID=38023905
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2006/043237 WO2007056313A2 (en) | 2005-11-07 | 2006-11-06 | Allowing network access for proxy mobile ip cases for nodes that do not support chap authentication |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP1946482B1 (en) |
WO (1) | WO2007056313A2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009155807A1 (en) * | 2008-06-25 | 2009-12-30 | 华为技术有限公司 | Pre-authentication method, authentication system and authentication apparatus |
EP2477429A1 (en) * | 2009-09-10 | 2012-07-18 | ZTE Corporation | Method, apparatus and system for home agent obtaining mobile node-home agent key in proxy mobile internet protocol |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5586260A (en) | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
WO2001013666A1 (en) | 1999-08-16 | 2001-02-22 | Nokia Networks Oy | Authentication in a mobile communications system |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6785823B1 (en) * | 1999-12-03 | 2004-08-31 | Qualcomm Incorporated | Method and apparatus for authentication in a wireless telecommunications system |
JP2001224070A (en) * | 2000-02-09 | 2001-08-17 | Fujitsu Ltd | Mobile communication system and its method |
US8195940B2 (en) * | 2002-04-05 | 2012-06-05 | Qualcomm Incorporated | Key updates in a mobile wireless system |
US6829473B2 (en) * | 2002-07-25 | 2004-12-07 | Utstarcom, Inc. | Roaming and hand-off support for prepaid billing for wireless data networks |
US6956846B2 (en) * | 2002-08-16 | 2005-10-18 | Utstarcom Incorporated | System and method for foreign agent control node redundancy in a mobile internet protocol network |
US7675885B2 (en) * | 2003-12-03 | 2010-03-09 | Qualcomm Incorporated | Methods and apparatus for CDMA2000/GPRS roaming |
-
2006
- 2006-11-06 WO PCT/US2006/043237 patent/WO2007056313A2/en active Application Filing
- 2006-11-06 EP EP06836995.8A patent/EP1946482B1/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5586260A (en) | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
WO2001013666A1 (en) | 1999-08-16 | 2001-02-22 | Nokia Networks Oy | Authentication in a mobile communications system |
Non-Patent Citations (2)
Title |
---|
MUN GI CHOI ET AL.: "A new multimedia network architecture using 3G CDMA2000", VEHICULAR TECHNOLOGY CONFERENCE 2000. IEEE VTS FALL VTC 2000. 52ND SEPT. 24-28, 2000, PISCATAWAY, NJ, USA, IEEE, vol. 6, 24 September 2000 (2000-09-24), pages 2937 - 2944 |
See also references of EP1946482A4 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009155807A1 (en) * | 2008-06-25 | 2009-12-30 | 华为技术有限公司 | Pre-authentication method, authentication system and authentication apparatus |
CN101616407B (en) * | 2008-06-25 | 2011-04-27 | 华为技术有限公司 | Pre-authentication method and authentication system |
US8407474B2 (en) | 2008-06-25 | 2013-03-26 | Huawei Technologies Co., Ltd. | Pre-authentication method, authentication system and authentication apparatus |
EP2477429A1 (en) * | 2009-09-10 | 2012-07-18 | ZTE Corporation | Method, apparatus and system for home agent obtaining mobile node-home agent key in proxy mobile internet protocol |
EP2477429A4 (en) * | 2009-09-10 | 2017-05-10 | ZTE Corporation | Method, apparatus and system for home agent obtaining mobile node-home agent key in proxy mobile internet protocol |
Also Published As
Publication number | Publication date |
---|---|
WO2007056313A3 (en) | 2007-07-05 |
EP1946482B1 (en) | 2020-01-29 |
EP1946482A2 (en) | 2008-07-23 |
EP1946482A4 (en) | 2009-01-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8042154B2 (en) | Allowing network access for proxy mobile IP cases for nodes that do not support CHAP authentication | |
US7496057B2 (en) | Methods and apparatus for optimizations in 3GPP2 networks using mobile IPv6 | |
US7840217B2 (en) | Methods and apparatus for achieving route optimization and location privacy in an IPV6 network | |
US7626963B2 (en) | EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure | |
US8584207B2 (en) | Infrastructure-less bootstrapping: trustless bootstrapping to enable mobility for mobile devices | |
US8165290B2 (en) | Methods and apparatus for bootstrapping mobile-foreign and foreign-home authentication keys in mobile IP | |
US7152238B1 (en) | Enabling mobility for point to point protocol (PPP) users using a node that does not support mobility | |
US7130629B1 (en) | Enabling services for multiple sessions using a single mobile node | |
US7536464B1 (en) | Methods and apparatus for performing layer 2 authentication and service selection in SSG based networks | |
US8059661B2 (en) | Methods and apparatus for using DHCP for home address management of nodes attached to an edge device and for performing mobility and address management as a proxy home agent | |
US9955344B2 (en) | Mobile network device multi-link optimizations | |
US7870389B1 (en) | Methods and apparatus for authenticating mobility entities using kerberos | |
US7778229B2 (en) | Optimized IP address use in a mobile IP environment | |
US20070091842A1 (en) | Method for supporting mobility for dynamic windows clients in a wireless lan network | |
US7447186B2 (en) | Methods and apparatus for implementing mobile IPv6 route optimization enhancements | |
US7409549B1 (en) | Methods and apparatus for dynamic home agent assignment in mobile IP | |
US7447188B1 (en) | Methods and apparatus for supporting mobile IP proxy registration in a system implementing mulitple VLANs | |
EP1946482B1 (en) | Allowing network access for proxy mobile ip cases for nodes that do not support chap authentication |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200680041553.5 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2006836995 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |