CA2521510C - System and method for providing end to end authentication in a network environment - Google Patents
System and method for providing end to end authentication in a network environment Download PDFInfo
- Publication number
- CA2521510C CA2521510C CA2521510A CA2521510A CA2521510C CA 2521510 C CA2521510 C CA 2521510C CA 2521510 A CA2521510 A CA 2521510A CA 2521510 A CA2521510 A CA 2521510A CA 2521510 C CA2521510 C CA 2521510C
- Authority
- CA
- Canada
- Prior art keywords
- authentication
- protocol
- lns
- mobile terminal
- ggsn
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/162—Implementing security features at a particular protocol layer at the data link layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- 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/0272—Virtual private networks
-
- 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
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
Abstract
A method for executing end to end authentication in a network environment is provided that includes initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS) and communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN
being operable to communicate an activate context response that may be received by the mobile terminal. An authentication response may be calculated by using a secret value and a challenge value which is provided by the GGSN, the authentication response being used to establish a communication session associated with the mobile terminal.
being operable to communicate an activate context response that may be received by the mobile terminal. An authentication response may be calculated by using a secret value and a challenge value which is provided by the GGSN, the authentication response being used to establish a communication session associated with the mobile terminal.
Description
SYSTEM AND METHOD FOR PROVIDING END TO END
AUTHENTTCATION IN A NETWORK ENVIRONMENT
TECHNICAL FIELD OF THE INVENTION
This invention relates in general to the field of communications and more particularly to a system and method for. providing end to end authentication in a network environment.
BACKGROUND OF THE INVENTION
Networking architectureshave grown increasingly complex in communications environments. In addition, the augmentation of clients or end users wishing to communicate in a network environment has caused many networking configurations and systems to respond by adding elements to accommodate the increase in networking traffic. Communication tunnels or links may be used in order to establish or to authenticate an entity via a network, whereby an end user or an object may initiate a tunneling protocol by invoking a selected location or a designated network node. The network node or selected location may then provide a platform that the end user may use to conduct a communication session.
As the subscriber base of end users increases, proper routing, viable security, effective authentication, and efficient management of communication sessions and data flows becomes even more critical. In cases where improper authentication protocols are executed, certain network components may become
AUTHENTTCATION IN A NETWORK ENVIRONMENT
TECHNICAL FIELD OF THE INVENTION
This invention relates in general to the field of communications and more particularly to a system and method for. providing end to end authentication in a network environment.
BACKGROUND OF THE INVENTION
Networking architectureshave grown increasingly complex in communications environments. In addition, the augmentation of clients or end users wishing to communicate in a network environment has caused many networking configurations and systems to respond by adding elements to accommodate the increase in networking traffic. Communication tunnels or links may be used in order to establish or to authenticate an entity via a network, whereby an end user or an object may initiate a tunneling protocol by invoking a selected location or a designated network node. The network node or selected location may then provide a platform that the end user may use to conduct a communication session.
As the subscriber base of end users increases, proper routing, viable security, effective authentication, and efficient management of communication sessions and data flows becomes even more critical. In cases where improper authentication protocols are executed, certain network components may become
2 overwhelmed or network traffic may be susceptible to breaks in security protocols. This scenario may compromise the validity of communication sessions and inhibit the effective flow of network traffic.
Accordingly, the ability to provide an effective mechanism to authenticate an end user/mobile terminal, or to offer an appropriate security protocol for a corresponding network provides a significant challenge to network operators, component manufacturers, and system designers.
SUMMARY OF THE INVENTION
From the foregoing, it may be appreciated by those skilled in the art that a need has arisen for an improved communications approach that provides for more appropriate authentication procedures allowing an end to end protocol to be implemented. In accordance with one embodiment of the present invention, a system and method for providing end to end authentication in a network environment are provided that greatly reduce disadvantages and problems associated with conventional authentication techniques.
According to one embodiment of the present invention, there is provided a method for providing end to end authentication in a network environment that includes initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS) and communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN being
Accordingly, the ability to provide an effective mechanism to authenticate an end user/mobile terminal, or to offer an appropriate security protocol for a corresponding network provides a significant challenge to network operators, component manufacturers, and system designers.
SUMMARY OF THE INVENTION
From the foregoing, it may be appreciated by those skilled in the art that a need has arisen for an improved communications approach that provides for more appropriate authentication procedures allowing an end to end protocol to be implemented. In accordance with one embodiment of the present invention, a system and method for providing end to end authentication in a network environment are provided that greatly reduce disadvantages and problems associated with conventional authentication techniques.
According to one embodiment of the present invention, there is provided a method for providing end to end authentication in a network environment that includes initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS) and communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN being
3 operable to communicate an activate context response that may be received by the mobile terminal. An authentication response may be calculated by using a secret value and a challenge value which is provided by the GGSN, the authentication response being used to establish a communication session associated with the mobile terminal.
Certain embodiments of the present invention may provide a number of technical advantages. For example, according to one embodiment of the present invention a communications approach is provided that allows for enhanced security. A security hole may be effectively closed in a corresponding authentication protocol. For example, an authentication challenge may be communicated in a first create response and an authentication response may be delivered in a second create request, whereby such a pair previously was communicated in a single message.
Accordingly, even in scenarios where some person or entity intercepts both of these messages and is able to extract the pair (challenge and response), such an entity would not be able to use this data to connect to a corresponding network node (e. g. a layer two tunnel protocol (L2TP) network sever (LNS)). This is due to the fact that the LNS will communicate a different challenge during the next instance of authentication. In order to be properly authenticated, possession of the authentication secret is therefore needed.
Yet another technical advantage associated with one embodiment of the present invention is the result of the operation of the communications approach. The provided architecture allows a multitude of diverse protocols and processes to be implemented in conjunction with an end-to-end scenario. For example, point to point (PPP)
Certain embodiments of the present invention may provide a number of technical advantages. For example, according to one embodiment of the present invention a communications approach is provided that allows for enhanced security. A security hole may be effectively closed in a corresponding authentication protocol. For example, an authentication challenge may be communicated in a first create response and an authentication response may be delivered in a second create request, whereby such a pair previously was communicated in a single message.
Accordingly, even in scenarios where some person or entity intercepts both of these messages and is able to extract the pair (challenge and response), such an entity would not be able to use this data to connect to a corresponding network node (e. g. a layer two tunnel protocol (L2TP) network sever (LNS)). This is due to the fact that the LNS will communicate a different challenge during the next instance of authentication. In order to be properly authenticated, possession of the authentication secret is therefore needed.
Yet another technical advantage associated with one embodiment of the present invention is the result of the operation of the communications approach. The provided architecture allows a multitude of diverse protocols and processes to be implemented in conjunction with an end-to-end scenario. For example, point to point (PPP)
4 regeneration may be operable with any LNS because the necessity for an attribute value pair (AVP) to communicate the challenge in the incoming call connected (ICCN) message is eliminated. Aside from this benefit, the present communications approach further provides for the successful operation of an authentication rechallenge in cases where the PCO field addition to the update context request/response is accepted. Certain embodiments of the present invention may enjoy some, all, or none of these advantages. Other technical advantages may be readily apparent to one skilled in the art from the following figures, description, and claims.
BRIEF DESCRTPTION OF THE DRAWINGS
To provide a more complete understanding of the present invention and features and advantages thereof, reference is made to the following description, taken in conjunction with. the accompanying figures, wherein like reference numerals represent like parts, in which:
FIGURE l is a simplified block diagram of a communications system for executing an end to end authentication in a network environment in accordance with one embodiment of the present invention; and FIGURE 2 is a flowchart illustrating a series of example steps associated with a method for executing an end to end authentication in a network environment.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE
FIGURE 1 is a simplified block diagram of a communication system 10 for communicating data in a
BRIEF DESCRTPTION OF THE DRAWINGS
To provide a more complete understanding of the present invention and features and advantages thereof, reference is made to the following description, taken in conjunction with. the accompanying figures, wherein like reference numerals represent like parts, in which:
FIGURE l is a simplified block diagram of a communications system for executing an end to end authentication in a network environment in accordance with one embodiment of the present invention; and FIGURE 2 is a flowchart illustrating a series of example steps associated with a method for executing an end to end authentication in a network environment.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE
FIGURE 1 is a simplified block diagram of a communication system 10 for communicating data in a
5 network environment. Communication system 10 includes a mobile terminal 12, a radio access network (RAN) 14, a serving general packet radio service (GPRS) support node (SGSN) 18, and an Internet protocol (TP) network 20.
Additionally, communication system 10 may include multiple gateway GPRS support nodes (GGSNs) 30a-b, multiple layer two tunnel protocol (L2TP) access concentrators (LACs) 34a-b, an Internet 38, an L2TP
network server (LNS) 64, and an authentication, authorization, and accounting (AAA) server 40. FIGURE 1 may be generally configured or arranged to represent a 2.5G communication architecture applicable to a Global System for Mobile (GSM) environment in accordance with a particular embodiment of the present invention. However, the 2.5G architecture is offered for purposes of example only and may alternatively be substituted with any suitable networking protocol or arrangement that provides a communicative platform for communication system 10.
For example, communication system 10 may cooperate with any version of a GPRS tunneling protocol (GTP) that includes authentication operations. This may be inclusive of first generation, 2G, and 3G architectures that provide features for executing authentication.
In accordance with the teachings of the present invention, communication system l0 provides a platform in which to execute an end to end point to point (PPP) authentication (e. g. in the context of a challenge handshake authentication protocol (CHAP)). This may be in contrast to other architectures that execute
Additionally, communication system 10 may include multiple gateway GPRS support nodes (GGSNs) 30a-b, multiple layer two tunnel protocol (L2TP) access concentrators (LACs) 34a-b, an Internet 38, an L2TP
network server (LNS) 64, and an authentication, authorization, and accounting (AAA) server 40. FIGURE 1 may be generally configured or arranged to represent a 2.5G communication architecture applicable to a Global System for Mobile (GSM) environment in accordance with a particular embodiment of the present invention. However, the 2.5G architecture is offered for purposes of example only and may alternatively be substituted with any suitable networking protocol or arrangement that provides a communicative platform for communication system 10.
For example, communication system 10 may cooperate with any version of a GPRS tunneling protocol (GTP) that includes authentication operations. This may be inclusive of first generation, 2G, and 3G architectures that provide features for executing authentication.
In accordance with the teachings of the present invention, communication system l0 provides a platform in which to execute an end to end point to point (PPP) authentication (e. g. in the context of a challenge handshake authentication protocol (CHAP)). This may be in contrast to other architectures that execute
6 authentication between a LAC element and an LNS element, The authentication mechanism provided by communication system 10 provides a challenge request to be sent from LNS 64 all the way to mobile terminal 12. The challenge value may then be used to calculate the response. The response may then be sent from mobile terminal 12 to LNS
64 in a different message. This allows only the entity holding the secret value associated with the CHAP
mechanism to send the response. Thus, even in cases where someone may receive the challenge or the response, authentication may not be executed unless the CHAP secret value is obtained.
For purposes of teaching, it is helpful to provide some overview of the way in which an authentication protocol (e.g. CHAP) functions. This description is offered for purposes of example only and should not be construed in any way to limit the principles and features of the present invention. CHAP may operate to verify the identity of a peer using a three-way handshake. The following general steps may be performed in CHAP: 1) after the link establishment phase is complete, the authenticator may send a challenge message to the peer;
2) the peer may respond with a value calculated using a one-way hash function (potentially over the secret and the challenge); and 3) the authenticator may check the response against its own calculation of the expected hash value. If the values match, the authentication is successful. If the values do not match, the connection may be terminated.
This authentication method relies on a "secret"
value known only to the authenticator and the peer. The secret is not necessarily communicated over the link.
Although the authentication is only one-way, by
64 in a different message. This allows only the entity holding the secret value associated with the CHAP
mechanism to send the response. Thus, even in cases where someone may receive the challenge or the response, authentication may not be executed unless the CHAP secret value is obtained.
For purposes of teaching, it is helpful to provide some overview of the way in which an authentication protocol (e.g. CHAP) functions. This description is offered for purposes of example only and should not be construed in any way to limit the principles and features of the present invention. CHAP may operate to verify the identity of a peer using a three-way handshake. The following general steps may be performed in CHAP: 1) after the link establishment phase is complete, the authenticator may send a challenge message to the peer;
2) the peer may respond with a value calculated using a one-way hash function (potentially over the secret and the challenge); and 3) the authenticator may check the response against its own calculation of the expected hash value. If the values match, the authentication is successful. If the values do not match, the connection may be terminated.
This authentication method relies on a "secret"
value known only to the authenticator and the peer. The secret is not necessarily communicated over the link.
Although the authentication is only one-way, by
7 negotiating CHAP in both directions, a user may utilize the same secret set for mutual authentication.
Additional details relating to the operation of CHAP, as well as its potential application to communication system 10 are provided below.
Mobile terminal 12 represents an end user, a client, or a customer wishing to initiate a communication in communication system 10 via IP network 20. Mobile terminal 12 may be inclusive of devices used to initiate a communication, such as a computer, a personal digital assistant (PDA), a laptop or an electronic notebook, a telephone, a mobile station, or any other device, component, element, or object capable of initiating voice or data exchanges within communication system 10. Mobile terminal 12 may also be inclusive of a suitable interface to the human user, such as a microphone, a display, a keyboard, or other terminal equipment (such as for example an interface to a personal computer or to a facsimile machine in cases where mobile terminal 12 is used as a modem). Mobile terminal 12 may also be any device that seeks to initiate a communication on behalf of another entity or element, such as a program, a database, or any other component, device, element, or object capable of initiating a voice or a data exchange within communication system 10. Data, as used herein in this document, refers to any type of numeric, voice, video, audio-visual, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another. In one embodiment, mobile terminal 12 includes software operable to facilitate the end to end authentication process in accordance with the teachings of the present invention. This software may
Additional details relating to the operation of CHAP, as well as its potential application to communication system 10 are provided below.
Mobile terminal 12 represents an end user, a client, or a customer wishing to initiate a communication in communication system 10 via IP network 20. Mobile terminal 12 may be inclusive of devices used to initiate a communication, such as a computer, a personal digital assistant (PDA), a laptop or an electronic notebook, a telephone, a mobile station, or any other device, component, element, or object capable of initiating voice or data exchanges within communication system 10. Mobile terminal 12 may also be inclusive of a suitable interface to the human user, such as a microphone, a display, a keyboard, or other terminal equipment (such as for example an interface to a personal computer or to a facsimile machine in cases where mobile terminal 12 is used as a modem). Mobile terminal 12 may also be any device that seeks to initiate a communication on behalf of another entity or element, such as a program, a database, or any other component, device, element, or object capable of initiating a voice or a data exchange within communication system 10. Data, as used herein in this document, refers to any type of numeric, voice, video, audio-visual, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another. In one embodiment, mobile terminal 12 includes software operable to facilitate the end to end authentication process in accordance with the teachings of the present invention. This software may
8 PCT/US2004/013392 properly interface with corresponding software provided in a selected GGSN 30a-b. Alternatively, mobile terminal 12 may include hardware, algorithms, devices, components, elements, or objects operable to effectuate the end to end authentication operations as described herein.
RAN Z4 is a communications interface between mobile terminal 12 and SGSN 18. RAN 14 may also be representative of terminal equipment (TE) (and accordingly these terms may be used interchangeable herein in this document) used to offer a communications platform to one or more mobile terminals 12. RAN 14 may comprise a base transceiver station and a base station controller. The communications interface provided by RAN
14 offers connectivity and allows data to be exchanged between mobile terminal 12 and any number of selected elements within communication system 10. RAN 14 may also facilitate the delivery of a request packet generated by mobile terminal 12 and the reception of information sought by mobile terminal 12. RAN 14 is only one example of a communications interface between mobile terminal 12 and SGSN 18. Other types of communications interfaces may be used for a desired network design and based on particular needs.
SGSN 18 and GGSNs 30a-b cooperate in order to facilitate a communication session involving mobile terminal 12. GGSNs 30a-b are communications or network nodes that may be working in conjunction with multiple SGSNs 18 to provide a communications medium in a GPRS
service network environment in communicating data exchanges within communication system 10. In one embodiment, GGSNs 30a-b include software operable to facilitate the end to end authentication process in accordance with the teachings of the present invention.
RAN Z4 is a communications interface between mobile terminal 12 and SGSN 18. RAN 14 may also be representative of terminal equipment (TE) (and accordingly these terms may be used interchangeable herein in this document) used to offer a communications platform to one or more mobile terminals 12. RAN 14 may comprise a base transceiver station and a base station controller. The communications interface provided by RAN
14 offers connectivity and allows data to be exchanged between mobile terminal 12 and any number of selected elements within communication system 10. RAN 14 may also facilitate the delivery of a request packet generated by mobile terminal 12 and the reception of information sought by mobile terminal 12. RAN 14 is only one example of a communications interface between mobile terminal 12 and SGSN 18. Other types of communications interfaces may be used for a desired network design and based on particular needs.
SGSN 18 and GGSNs 30a-b cooperate in order to facilitate a communication session involving mobile terminal 12. GGSNs 30a-b are communications or network nodes that may be working in conjunction with multiple SGSNs 18 to provide a communications medium in a GPRS
service network environment in communicating data exchanges within communication system 10. In one embodiment, GGSNs 30a-b include software operable to facilitate the end to end authentication process in accordance with the teachings of the present invention.
9 This software may properly interface with corresponding software provided in mobile terminal 12. Alternatively, mobile terminal 12 may include any suitable hardware, algorithms, devices, components, elements, or objects operable to effectuate the end to end authentication operations as described herein. GGSNs 30a-b may also be inclusive of a walled garden used to control user access to web content or services. GPRS represents a packet-based data bearer service for communication services that may be delivered as a network overlay for any type of suitable network configuration or platform. GPRS
generally applies packet-radio and packet switching principles to transfer data packets in an efficient way between GSM elements or units and external packet data networks. GPRS may support multiple Internet communication protocols and may enable existing IP, X..25, or any other suitable applications or platforms to operate over GSM connections.
IP network 20 represents a series of points or nodes of interconnected communication paths for receiving and transmitting packets of information that propagate through communication system 10. IP network 20 offers a communicative interface between mobile terminal 12 and selected GGSNs 30a-b and may be representative of a GPRS
service provider or any suitable local area network (LAN), wireless local area network (WLAN), metropolitan area network (MAN), wide area network (WAN), virtual private network (VPN), or any other appropriate architecture or system that facilitates communications in a network environment. IP network 20 implements a user datagram protocol (UDP)/internet protocol (UDP/TP) communication language protocol in a particular embodiment of the present invention; however, IP network 20 may alternatively implement any other suitable communication protocol for transmitting and receiving data or information within communication system 10. In certain scenarios, GTP may be used as a tunneling 5 protocol on top of UDP/IP where appropriate.
LACs 34a-b are communication nodes or software modules that act as one side of an L2TP tunnel end point and may be a peer to LNS 64. LACs 34a-b may be positioned between LNS 64 and the client and may forward
generally applies packet-radio and packet switching principles to transfer data packets in an efficient way between GSM elements or units and external packet data networks. GPRS may support multiple Internet communication protocols and may enable existing IP, X..25, or any other suitable applications or platforms to operate over GSM connections.
IP network 20 represents a series of points or nodes of interconnected communication paths for receiving and transmitting packets of information that propagate through communication system 10. IP network 20 offers a communicative interface between mobile terminal 12 and selected GGSNs 30a-b and may be representative of a GPRS
service provider or any suitable local area network (LAN), wireless local area network (WLAN), metropolitan area network (MAN), wide area network (WAN), virtual private network (VPN), or any other appropriate architecture or system that facilitates communications in a network environment. IP network 20 implements a user datagram protocol (UDP)/internet protocol (UDP/TP) communication language protocol in a particular embodiment of the present invention; however, IP network 20 may alternatively implement any other suitable communication protocol for transmitting and receiving data or information within communication system 10. In certain scenarios, GTP may be used as a tunneling 5 protocol on top of UDP/IP where appropriate.
LACs 34a-b are communication nodes or software modules that act as one side of an L2TP tunnel end point and may be a peer to LNS 64. LACs 34a-b may be positioned between LNS 64 and the client and may forward
10 packets to and from each. Packets communicated from LACs 34a-b to LNS 64 may require some tunneling with the L2TP
protocol. The connection from LACs 34a-b to the client may be presented through analog for example. LACs 34a-b may be provided external to GGSNs 30a-b where appropriate and include any suitable hardware, software, object, element, algorithm, device, or component operable to effectuate the operations thereof.
Internet 38 represents a public Internet that offers a communicative interface between GGSNs 30a-b and LNS 64 and may be any LAN, WLAN, MAN, WAN, VPN, Intranet or any other appropriate architecture or system that facilitates communications in a network environment. Internet 38 implements a UDP/IP communication language protocol in a particular embodiment of the present invention. However, Internet 38 may alternatively implement any other suitable communication protocol for transmitting and receiving data or information within communication system 10. Additionally, Internet 38 may interface with any additional element or object in order to facilitate proper end to end authentication in communication system 10. L2TP may be implemented on top of UDP/IP in certain embodiments where appropriate.
protocol. The connection from LACs 34a-b to the client may be presented through analog for example. LACs 34a-b may be provided external to GGSNs 30a-b where appropriate and include any suitable hardware, software, object, element, algorithm, device, or component operable to effectuate the operations thereof.
Internet 38 represents a public Internet that offers a communicative interface between GGSNs 30a-b and LNS 64 and may be any LAN, WLAN, MAN, WAN, VPN, Intranet or any other appropriate architecture or system that facilitates communications in a network environment. Internet 38 implements a UDP/IP communication language protocol in a particular embodiment of the present invention. However, Internet 38 may alternatively implement any other suitable communication protocol for transmitting and receiving data or information within communication system 10. Additionally, Internet 38 may interface with any additional element or object in order to facilitate proper end to end authentication in communication system 10. L2TP may be implemented on top of UDP/IP in certain embodiments where appropriate.
11 AAA server 40 is a server program that receives end user requests for access to networking equipment or resources. 'Networking resources' refers to any device, component, or element that provides some functionality to mobile terminal 12 communicating in communication system 10. AAA server 40 may also provide AAA services and management for a corresponding network. Authorization generally refers to the process of giving mobile terminal
12 permission to do or to access something. In multi-user computer systems, a system administrator may define for the system which end users are allowed access to given locations in the system and, further, what privileges are provided for mobile terminal 12. Once mobile terminal 12 has logged into a network, such as for example IP network 20, the network may wish to identify what resources mobile terminal 12 is given during the communication session. Thus, authorization within communication system 10 may be seen as both a preliminary setting up of permissions by a system administrator and the actual checking or verification of the permission values that have been set up when mobile terminal 12 is attempting access to a selected area. Authentication generally refers to the process of determining whether mobile terminal 12 is in fact who or what it is declared to be. In the case of private or public computer networks, authentication may be done through the use of unique identification elements such as a user identity or log-on passwords. Knowledge of the password offers a presumption that mobile terminal 12 is authentic.
Accounting generally refers to financial or session information associated with each mobile terminal 12 or each network and may additionally include trafficking information, session timing information, data transfer statistics, or information relating to other information flows within communication system 10.
AAA server 40 may receive an IP address associated with mobile terminal 12 and other parameters from any suitable network source, or alternatively from a dynamic host configuration protocol (DHCP) server or a domain name system (DNS) database element, in order to direct data to be communicated to mobile terminal 12. AAA
server 40 may include any suitable hardware, software, component, or element that operates to receive data associated with mobile terminal 12 and provide corresponding AAA-related functions to network components within communication system 10. Authorization and IP
address management may be retrieved from AAA server 40 from LNS 64, which may be provided to address secure services for mobile terminal 12 where appropriate.
In an alternative embodiment of the present invention, communication system 10 may be implemented with any other suitable server (used to supplant AAA
server 40) or with any other passive (or incidental) server or element that replaces AAA server 40 and operates as another network element. Additionally, communication system 10 may be configured without AAA
server 40 in accordance with the teachings of the present invention. In such. an arrangement, other suitable intra-communications between various elements within communication system 10 may be executed in the absence of AAA server 40 in accordance to particular needs.
LNS 64 is a node that operates as one side of an L2TP tunnel end point and is a peer to LACs 34a-b. LNS
64 may operate as the logical termination point of a PPP
session that is being tunneled from a client (e. g. mobile terminal 12) by LAC 34a or LAC 34b. A communications
Accounting generally refers to financial or session information associated with each mobile terminal 12 or each network and may additionally include trafficking information, session timing information, data transfer statistics, or information relating to other information flows within communication system 10.
AAA server 40 may receive an IP address associated with mobile terminal 12 and other parameters from any suitable network source, or alternatively from a dynamic host configuration protocol (DHCP) server or a domain name system (DNS) database element, in order to direct data to be communicated to mobile terminal 12. AAA
server 40 may include any suitable hardware, software, component, or element that operates to receive data associated with mobile terminal 12 and provide corresponding AAA-related functions to network components within communication system 10. Authorization and IP
address management may be retrieved from AAA server 40 from LNS 64, which may be provided to address secure services for mobile terminal 12 where appropriate.
In an alternative embodiment of the present invention, communication system 10 may be implemented with any other suitable server (used to supplant AAA
server 40) or with any other passive (or incidental) server or element that replaces AAA server 40 and operates as another network element. Additionally, communication system 10 may be configured without AAA
server 40 in accordance with the teachings of the present invention. In such. an arrangement, other suitable intra-communications between various elements within communication system 10 may be executed in the absence of AAA server 40 in accordance to particular needs.
LNS 64 is a node that operates as one side of an L2TP tunnel end point and is a peer to LACs 34a-b. LNS
64 may operate as the logical termination point of a PPP
session that is being tunneled from a client (e. g. mobile terminal 12) by LAC 34a or LAC 34b. A communications
13 tunnel generally exists between an LAC-LNS pair. The tunnel may consist of a control connection and zero or more L2TP sessions. The tunnel may carry encapsulated PPP datagrams and control messages between the LAC and the LNS . The process may be equivalent for a layer two forwarding (L2F) protocol.
In operation of an example CHAP scenario, a GPRS end user communicates data traffic from TE that may be connected to a GPRS handset and be delivered to an Internet and/or corporate networks through GGSNs 30a-b.
The PPP regeneration feature may be used to regenerate a PPP session for an incoming user IP session at a selected GGSN 30a-b, and may establish an L2TP tunnel to deliver these IP packets to its corresponding LNS in encapsulated PPP.
A CHAP authentication procedure not provided with the capabilities of communications system 10 may behave as follows. First, a PPP negotiation takes place between TE and mobile terminal 12. The TE responds to the challenge sent by mobile terminal 12 and mobile terminal l2 responds with a success signal without doing any actual authentication. TE may then send an Internet protocol control protocol (IPCP) configure request, and at this point the packet data protocol (PDP) context creation starts. (TE may use the secret value to calculate the response for the challenge that may be sent by mobile terminal 12.) Mobile terminal 12 sends an activate context request to SGSN 18, which is forwarded as create context request by SGSN 18 to GGSN 30a-b.
Second, the (PCO) field in the create context request received by a selected GGSN 30a-b includes the challenge and response. A selected GGSN 30a-b may establish an L2TP tunnel to LNS 64 (corresponding to the access point
In operation of an example CHAP scenario, a GPRS end user communicates data traffic from TE that may be connected to a GPRS handset and be delivered to an Internet and/or corporate networks through GGSNs 30a-b.
The PPP regeneration feature may be used to regenerate a PPP session for an incoming user IP session at a selected GGSN 30a-b, and may establish an L2TP tunnel to deliver these IP packets to its corresponding LNS in encapsulated PPP.
A CHAP authentication procedure not provided with the capabilities of communications system 10 may behave as follows. First, a PPP negotiation takes place between TE and mobile terminal 12. The TE responds to the challenge sent by mobile terminal 12 and mobile terminal l2 responds with a success signal without doing any actual authentication. TE may then send an Internet protocol control protocol (IPCP) configure request, and at this point the packet data protocol (PDP) context creation starts. (TE may use the secret value to calculate the response for the challenge that may be sent by mobile terminal 12.) Mobile terminal 12 sends an activate context request to SGSN 18, which is forwarded as create context request by SGSN 18 to GGSN 30a-b.
Second, the (PCO) field in the create context request received by a selected GGSN 30a-b includes the challenge and response. A selected GGSN 30a-b may establish an L2TP tunnel to LNS 64 (corresponding to the access point
14 name) . This CHAP challenge in the PCO is sent to LNS 64 via an attribute value pairs (AVPs) in L2TP's incoming-call-connected (ICON) message during the tunnel setup.
Third, PPP negotiation starts between a selected GGSN 30a-b and LNS 64. LNS 64 sends that same challenge during the CHAP authentication phase to GGSN 30a-b, and GGSN 30a-b sends the CHAP response extracted from PCO.
Note that is an issue because LNS 64 is just authenticating a selected LAC 34a-b, but not mobile terminal 12 itself.
There are numerous problems with such an approach.
First, a security hole exists; if anyone were to access or receive any challenge response pair elements that are communicated in the PCO field, such an entity could get connected to LNS 64 without knowing the secret value.
Such. an entity could theoretically communicate the (challenge, response) pair in the PCO field and pretend to be in possession of the secret, LNS 64 would then be forced by a given GGSN 30a-b to send that challenge.
A second problem that may occur in such a process is that a CHAP rechallenge does not work unless a proprietary mechanism is in place with forces LNS 64 to rechallenge with the same secret value. A third problem with such an authentication process is that it is entirely possible that mobile terminal 12/TE may not even be performing PPP that allows these entities to attach to GGSNs 30a-b/LNS 64. Instead, these entities may behave as a middle node, and retrieve the above pair, and use that in the regeneration PPP session from GGSNs 30a-b to LNS 64. Because PPP is not done between the user and LNS
64 in such a scenario, but only between LACs 34a-b and LNS 64, this exposes a significant security hole.
Communication system 10 obviates these problems by providing an architecture that enforces an end to end PPP
CHAP, rather than between LACs 34a-b and LNS 64. In an example scenario, the PDP context activation may be broken down into two steps. In a first step, mobile 5 terminal 12 sends the activate context request once the link control protocol (LCP) negotiation is done with TE.
The PCO field contains the LCP option (including a selected authentication protocol). A selected GGSN 30a-b establishes an L2TP tunnel and PPP negotiation starts.
10 When LNS 64 sends the CHAP challenge, a selected GGSN
30a-b sends a create context response to SGSN 18 with that challenge in the PCO field. A new cause value can be used in a create context response ("chap in progress").
Third, PPP negotiation starts between a selected GGSN 30a-b and LNS 64. LNS 64 sends that same challenge during the CHAP authentication phase to GGSN 30a-b, and GGSN 30a-b sends the CHAP response extracted from PCO.
Note that is an issue because LNS 64 is just authenticating a selected LAC 34a-b, but not mobile terminal 12 itself.
There are numerous problems with such an approach.
First, a security hole exists; if anyone were to access or receive any challenge response pair elements that are communicated in the PCO field, such an entity could get connected to LNS 64 without knowing the secret value.
Such. an entity could theoretically communicate the (challenge, response) pair in the PCO field and pretend to be in possession of the secret, LNS 64 would then be forced by a given GGSN 30a-b to send that challenge.
A second problem that may occur in such a process is that a CHAP rechallenge does not work unless a proprietary mechanism is in place with forces LNS 64 to rechallenge with the same secret value. A third problem with such an authentication process is that it is entirely possible that mobile terminal 12/TE may not even be performing PPP that allows these entities to attach to GGSNs 30a-b/LNS 64. Instead, these entities may behave as a middle node, and retrieve the above pair, and use that in the regeneration PPP session from GGSNs 30a-b to LNS 64. Because PPP is not done between the user and LNS
64 in such a scenario, but only between LACs 34a-b and LNS 64, this exposes a significant security hole.
Communication system 10 obviates these problems by providing an architecture that enforces an end to end PPP
CHAP, rather than between LACs 34a-b and LNS 64. In an example scenario, the PDP context activation may be broken down into two steps. In a first step, mobile 5 terminal 12 sends the activate context request once the link control protocol (LCP) negotiation is done with TE.
The PCO field contains the LCP option (including a selected authentication protocol). A selected GGSN 30a-b establishes an L2TP tunnel and PPP negotiation starts.
10 When LNS 64 sends the CHAP challenge, a selected GGSN
30a-b sends a create context response to SGSN 18 with that challenge in the PCO field. A new cause value can be used in a create context response ("chap in progress").
15 SGSN 18 will not create the context because the cause value is not "request accepted." It may relay back the create context response as an activate context response to mobile terminal 12. Mobile terminal 12 may extract the challenge from the PCO field in the activate response and send it as CHAP challenge to TE. When TE
sends a CHAP response to mobile terminal 12, mobile terminal 12 may send a CHAP-success to TE. TE may then send the IPCP configure request.
In a second step, mobile terminal 12 may send another activate context request, however this time including the CHAP response in the PCO field. A selected GGSN 30a-b, in receiving this create context request, may use this response value in the PPP CHAP response to LNS
64. LNS 64 may then certify this response and send back a CHAP-success to a given LAC 34a-b, which may just relay it in the PCO field of a create response to SGSN 18.
Such an operation effectively achieves an end-to-end CHAP
procedure. PPP regeneration may be operable with any
sends a CHAP response to mobile terminal 12, mobile terminal 12 may send a CHAP-success to TE. TE may then send the IPCP configure request.
In a second step, mobile terminal 12 may send another activate context request, however this time including the CHAP response in the PCO field. A selected GGSN 30a-b, in receiving this create context request, may use this response value in the PPP CHAP response to LNS
64. LNS 64 may then certify this response and send back a CHAP-success to a given LAC 34a-b, which may just relay it in the PCO field of a create response to SGSN 18.
Such an operation effectively achieves an end-to-end CHAP
procedure. PPP regeneration may be operable with any
16 suitable LNS 64 and, further, such an implementation effectively closes the security hole described above.
In particular embodiments, in order for a rechallenge to be functional, certain interactions may be appropriate. For example, when LNS 64 rechallenges mobile terminal 12, it may communicate that as part of the L2TP packet to a given GGSN 30a-b. The selected GGSN
30a-b may forward it to mobile terminal 12, The concept is that this CHAP-challenge value may be communicated in an "update context request'" from a selected GGSN 30a-b to SGSN 18 , It may also be appropriate for a PCO field to be added to provide an "update request" and an "update response" for such an operation. Mobile terminal 12 may extract the challenge from the PCO field and send it to TE. When TE responds, mobile terminal 12 may send a CHAP-success to TE and forward the CHAP-response in the PCO field of an "update context response" to a given GGSN
30a-b. The selected GGSN 30a-b may communicate the CHAP
response to LNS 64. If a selected GGSN 30a-b fails to get a success for that, the selected GGSN 30a-b may initiate a context deletion by communicating a delete context request.
Note that such an authentication approach closes the potential security hole that is present in other authentication methods. The CHAP challenge may be communicated in a first create response and a CHAP
response may be communicated in a second create request, whereas the pair would otherwise be delivered in one single message. Even in scenarios where some entity intercepts both of these messages and is able to extract the (challenge, response) pair, such an entity would not be able to use it to connect to LNS 64 because in the following instance LNS 64 will communicate a different
In particular embodiments, in order for a rechallenge to be functional, certain interactions may be appropriate. For example, when LNS 64 rechallenges mobile terminal 12, it may communicate that as part of the L2TP packet to a given GGSN 30a-b. The selected GGSN
30a-b may forward it to mobile terminal 12, The concept is that this CHAP-challenge value may be communicated in an "update context request'" from a selected GGSN 30a-b to SGSN 18 , It may also be appropriate for a PCO field to be added to provide an "update request" and an "update response" for such an operation. Mobile terminal 12 may extract the challenge from the PCO field and send it to TE. When TE responds, mobile terminal 12 may send a CHAP-success to TE and forward the CHAP-response in the PCO field of an "update context response" to a given GGSN
30a-b. The selected GGSN 30a-b may communicate the CHAP
response to LNS 64. If a selected GGSN 30a-b fails to get a success for that, the selected GGSN 30a-b may initiate a context deletion by communicating a delete context request.
Note that such an authentication approach closes the potential security hole that is present in other authentication methods. The CHAP challenge may be communicated in a first create response and a CHAP
response may be communicated in a second create request, whereas the pair would otherwise be delivered in one single message. Even in scenarios where some entity intercepts both of these messages and is able to extract the (challenge, response) pair, such an entity would not be able to use it to connect to LNS 64 because in the following instance LNS 64 will communicate a different
17 challenge. In order to be properly authenticated, possession of the CHAP secret is critical and is appropriately provided by communication system 10.
Additionally, it should be noted that such a communications approach would make PPP regeneration work with any type of LNS 64 because, for example, the potential need for an AVP (to communicate the challenge) in an ICCN message is eliminated. Additionally, the CHAP
rechallenge may work if the PCO addition to the update context request/response is accepted.
FIGURE 2 is a simplified flowchart illustrating a series of example steps associated with a method fox providing an end to end authentication in a network environment. The method begins at step 100 where mobile terminal 12 may communicate an activate context request once LCP negotiation is done with TE. The PCO field contains the LCP option (including the authentication protocol). A selected GGSN 30a-b may establish an L2TP
tunnel and PPP negotiation may be initiated at step 102.
When LNS 64 communicates the CHAP challenge, a selected GGSN 30a-b communicates a create context response to SGSN
Additionally, it should be noted that such a communications approach would make PPP regeneration work with any type of LNS 64 because, for example, the potential need for an AVP (to communicate the challenge) in an ICCN message is eliminated. Additionally, the CHAP
rechallenge may work if the PCO addition to the update context request/response is accepted.
FIGURE 2 is a simplified flowchart illustrating a series of example steps associated with a method fox providing an end to end authentication in a network environment. The method begins at step 100 where mobile terminal 12 may communicate an activate context request once LCP negotiation is done with TE. The PCO field contains the LCP option (including the authentication protocol). A selected GGSN 30a-b may establish an L2TP
tunnel and PPP negotiation may be initiated at step 102.
When LNS 64 communicates the CHAP challenge, a selected GGSN 30a-b communicates a create context response to SGSN
18 with that challenge in the PCO field at step 104. A
new cause value may be used (but not necessarily) in the create context response ("CHAP in progress").
SGSN 18 will not create the context because the cause value is not "request accepted." SGSN 18 may relay the create context response as an activate context response to mobile terminal 12 at step 106. Mobile terminal 12 may extract the challenge from the PCO in the activate response and send it as a CHAP challenge to TE
at step 108. When TE sends a CHAP response to mobile terminal 12, mobile terminal 12 may send a CHAP-success to TE at step 110 and TE may then send the IPCP configure request. In such a scenario, mobile terminal l2 may generate a CHAP response by using the secret and the challenge. Thus, the authentication response sent by mobile terminal 12 (a CHAP response calculated by mobile terminal 12 using the secret and the challenge) may be communicated as part of the PCO from mobile terminal 12 to GGSN 30a.
At step 112, mobile terminal 12 may send another activate context request, however this time including the CHAP response in the PCO. A selected GGSN 30a-b, in receiving this create context request, may use this response value in the PPP CHAP response to LNS 64 at step, 114. At step 116, LNS 64 may then certify this response and send back a CHAP-success to a given LAC 34a-b, which may j ust relay it in the PCO f field of a create response to SGSN 18. Such an operation effectively achieves an end-to-end CHAP procedure in communication system 10.
Some of the steps illustrated in FIGURE 2 may be changed or deleted where appropriate and additional steps may also be added to the flowchart. These changes may be based on specific communication architectures or particular interfacing arrangements and configurations of associated elements and do not depart from the scope or the teachings of the present invention.
It is important to recognize that FIGURE 2 illustrates just one of a myriad of potential implementations of communication system 10. A CHAP
rechallenge may work using a PCO in an update request or response for PPP regeneration with any type of LNS.
Additionally, even without PPP regeneration or a corresponding LNS, where an AAA server is coupled to a GGSN, a rechallenge may work using the same mechanism
new cause value may be used (but not necessarily) in the create context response ("CHAP in progress").
SGSN 18 will not create the context because the cause value is not "request accepted." SGSN 18 may relay the create context response as an activate context response to mobile terminal 12 at step 106. Mobile terminal 12 may extract the challenge from the PCO in the activate response and send it as a CHAP challenge to TE
at step 108. When TE sends a CHAP response to mobile terminal 12, mobile terminal 12 may send a CHAP-success to TE at step 110 and TE may then send the IPCP configure request. In such a scenario, mobile terminal l2 may generate a CHAP response by using the secret and the challenge. Thus, the authentication response sent by mobile terminal 12 (a CHAP response calculated by mobile terminal 12 using the secret and the challenge) may be communicated as part of the PCO from mobile terminal 12 to GGSN 30a.
At step 112, mobile terminal 12 may send another activate context request, however this time including the CHAP response in the PCO. A selected GGSN 30a-b, in receiving this create context request, may use this response value in the PPP CHAP response to LNS 64 at step, 114. At step 116, LNS 64 may then certify this response and send back a CHAP-success to a given LAC 34a-b, which may j ust relay it in the PCO f field of a create response to SGSN 18. Such an operation effectively achieves an end-to-end CHAP procedure in communication system 10.
Some of the steps illustrated in FIGURE 2 may be changed or deleted where appropriate and additional steps may also be added to the flowchart. These changes may be based on specific communication architectures or particular interfacing arrangements and configurations of associated elements and do not depart from the scope or the teachings of the present invention.
It is important to recognize that FIGURE 2 illustrates just one of a myriad of potential implementations of communication system 10. A CHAP
rechallenge may work using a PCO in an update request or response for PPP regeneration with any type of LNS.
Additionally, even without PPP regeneration or a corresponding LNS, where an AAA server is coupled to a GGSN, a rechallenge may work using the same mechanism
19 (potentially triggering an update request/response) on receiving a rechallenge from the AAA. server.
From a perspective associated with one example embodiment, a procedure associated with communication system 10 may be viewed in two parts. The first part is associated with context activation in a secure manner.
This may include contact from mobile terminal 12 to LAC
34a of GGSN 30a. An LCP setup may then occur between GGSN 30a and LNS 64. A CHAP challenge may also be communicated from LNS 64 to GGSN 30a. An activate context response may then be communicated from GGSN 30a to mobile terminal 12. An active request may then be communicated from mobile terminal 12 to GGSN 30a, whereby the PCO field includes a CHAP response. The CHAP
response may be communicated to LNS 64, which communicates back a CHAP success. A CHAP success may then be communicated to mobile terminal 12 after execution of a negotiation between LNS 64 and GGSN 30a.
In a second part, a rechallenge mechanism may be provided. LNS (or AAA server 40) may communicate a CHAP
rechallenge that is forwarded to GGSN 30a, which communicates an update context request to mobile terminal 12. Mobile terminal 12 may calculate a response using the secret and then communicate an update context response to GGSN 30a. A CHAP response may then be communicated from GGSN 30a to LNS 64, which may then return a CHAP success to GGSN 30a.
Although the present invention has been described in detail with reference to IP communications, communication system 10 may be used for any tunneling protocol involving authentication in a network environment. Any suitable communications that involve an end to end authentication may benefit from the teachings of the present invention. The use of mobile terminal 12 and IP
communications have only been offered for purposes of teaching and should not be construed to limit the scope of the present invention in any way.
5 In addition, communication system l0 may be extended to any scenario in which mobile terminal l2 is provided with an authentication capability (in the context of a wired or a wireless connection or coupling) and communicates with some type of access server (e.g. a 10 network access server (NAS), foreign agents, etc.).
Mobile, terminal 12 may use a dedicated connection of some form or use forms of multiple access protocols where appropriate. Access may be associated with PPP or alternatively with layer three protocols over an L2 layer 15 in accordance with particular needs. Such. an embodiment may include any suitable tunnel terminators and/or tunnel initiators.
Moreover, although communication system 10 has been illustrated with reference to particular authentication
From a perspective associated with one example embodiment, a procedure associated with communication system 10 may be viewed in two parts. The first part is associated with context activation in a secure manner.
This may include contact from mobile terminal 12 to LAC
34a of GGSN 30a. An LCP setup may then occur between GGSN 30a and LNS 64. A CHAP challenge may also be communicated from LNS 64 to GGSN 30a. An activate context response may then be communicated from GGSN 30a to mobile terminal 12. An active request may then be communicated from mobile terminal 12 to GGSN 30a, whereby the PCO field includes a CHAP response. The CHAP
response may be communicated to LNS 64, which communicates back a CHAP success. A CHAP success may then be communicated to mobile terminal 12 after execution of a negotiation between LNS 64 and GGSN 30a.
In a second part, a rechallenge mechanism may be provided. LNS (or AAA server 40) may communicate a CHAP
rechallenge that is forwarded to GGSN 30a, which communicates an update context request to mobile terminal 12. Mobile terminal 12 may calculate a response using the secret and then communicate an update context response to GGSN 30a. A CHAP response may then be communicated from GGSN 30a to LNS 64, which may then return a CHAP success to GGSN 30a.
Although the present invention has been described in detail with reference to IP communications, communication system 10 may be used for any tunneling protocol involving authentication in a network environment. Any suitable communications that involve an end to end authentication may benefit from the teachings of the present invention. The use of mobile terminal 12 and IP
communications have only been offered for purposes of teaching and should not be construed to limit the scope of the present invention in any way.
5 In addition, communication system l0 may be extended to any scenario in which mobile terminal l2 is provided with an authentication capability (in the context of a wired or a wireless connection or coupling) and communicates with some type of access server (e.g. a 10 network access server (NAS), foreign agents, etc.).
Mobile, terminal 12 may use a dedicated connection of some form or use forms of multiple access protocols where appropriate. Access may be associated with PPP or alternatively with layer three protocols over an L2 layer 15 in accordance with particular needs. Such. an embodiment may include any suitable tunnel terminators and/or tunnel initiators.
Moreover, although communication system 10 has been illustrated with reference to particular authentication
20 protocols, these protocols may be replaced by any suitable authentication processes or mechanisms. For example, communication system 10 may be used with a password authentication protocol (PAP) or an extensible authentication protocol (EAP). References to CHAP have been for purposes of example and teaching only and, accordingly, should be construed as such.
Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained by those skilled in the art and it is intended that the present invention encompass all such changes, substitutions, variations, alterations, and modifications as falling within the spirit and scope of the appended claims. Moreover, the present invention is not intended WO 2004/107098 . PCT/US2004/013392
Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained by those skilled in the art and it is intended that the present invention encompass all such changes, substitutions, variations, alterations, and modifications as falling within the spirit and scope of the appended claims. Moreover, the present invention is not intended WO 2004/107098 . PCT/US2004/013392
21 to be limited in any way by any statement in the specification that is not otherwise reflected in the appended claims.
Claims (24)
1. An apparatus for executing end to end authentication in a network environment, comprising:
a mobile terminal including a memory operable to store instructions and a processor operable to execute the instructions in order to initiate a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS) and to communicate an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN being operable to communicate an activate context response generated by the LNS that may be received by the mobile terminal, the mobile terminal being further operable to calculate an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
a mobile terminal including a memory operable to store instructions and a processor operable to execute the instructions in order to initiate a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS) and to communicate an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN being operable to communicate an activate context response generated by the LNS that may be received by the mobile terminal, the mobile terminal being further operable to calculate an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
2. The apparatus of Claim 1, wherein the mobile terminal communicates a configure request to a serving GPRS support node (SGSN) in order to establish the communication session, and wherein a point to point protocol (PPP) negotiation is initiated that involves the mobile terminal, a first stage of the PPP negotiation being associated with selecting which authentication protocol is going to be used.
3. The apparatus of Claim 2, wherein the GGSN
includes an L2TP access concentrator (LAC) operable to facilitate communications between the GGSN and the SGSN.
includes an L2TP access concentrator (LAC) operable to facilitate communications between the GGSN and the SGSN.
4. The apparatus of Claim 2, wherein the LNS
communicates an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates to the SGSN, the create context response being communicated to the mobile terminal in form of the activate context response, and wherein the mobile terminal is operable to extract the challenge value from the PCO field in the activate context request and communicate it to terminal equipment as an authentication challenge message.
communicates an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates to the SGSN, the create context response being communicated to the mobile terminal in form of the activate context response, and wherein the mobile terminal is operable to extract the challenge value from the PCO field in the activate context request and communicate it to terminal equipment as an authentication challenge message.
5. The apparatus of Claim 4, wherein the terminal equipment is operable to communicate the secret value to the mobile terminal.
6. The apparatus of Claim 1, wherein a PPP
negotiation begins between the GGSN and the LNS in order to establish the communications tunnel, the LNS
recognizing the authentication protocol to use based on the PPP negotiation.
negotiation begins between the GGSN and the LNS in order to establish the communications tunnel, the LNS
recognizing the authentication protocol to use based on the PPP negotiation.
7. The apparatus of Claim 1, wherein the authentication protocol is a selected one of a group consisting of:
a challenge handshake authentication protocol (CHAP);
a extensible authentication protocol (EAP); and a password authentication protocol (PAP).
a challenge handshake authentication protocol (CHAP);
a extensible authentication protocol (EAP); and a password authentication protocol (PAP).
8. An apparatus for executing end to end authentication in a network environment, comprising:
a gateway general packet radio service (GPRS) support node (GGSN) including a memory operable to store instructions and a processor operable to execute the instructions in order to receive an activate context request generated by a mobile terminal, the activate context request including an authentication protocol provided in a protocol configuration option (PCO) field, wherein the mobile terminal is operable to initiate a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS), the GGSN being operable to initiate a link control protocol (LCP) negotiation with the LNS and to communicate an activate context response generated by the LNS that may be received by the mobile terminal, the mobile terminal being further operable to calculate an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
a gateway general packet radio service (GPRS) support node (GGSN) including a memory operable to store instructions and a processor operable to execute the instructions in order to receive an activate context request generated by a mobile terminal, the activate context request including an authentication protocol provided in a protocol configuration option (PCO) field, wherein the mobile terminal is operable to initiate a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS), the GGSN being operable to initiate a link control protocol (LCP) negotiation with the LNS and to communicate an activate context response generated by the LNS that may be received by the mobile terminal, the mobile terminal being further operable to calculate an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
9. The apparatus of Claim 8, wherein the mobile terminal communicates a configure request to a serving GPRS support node (SGSN) in order to establish the communication session, and wherein a point to point protocol (PPP) negotiation is initiated that involves the mobile terminal, a first stage of the PPP negotiation being associated with selecting which authentication protocol is going to be used.
10. The apparatus of Claim 9, wherein the GGSN
includes an L2TP access concentrator (LAC) operable to facilitate communications between the GGSN and the SGSN.
includes an L2TP access concentrator (LAC) operable to facilitate communications between the GGSN and the SGSN.
11. The apparatus of Claim 9, wherein the LNS
communicates an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates to the SGSN, the create context response being communicated to the mobile terminal in form of the activate context response, and wherein the mobile terminal is operable to extract a challenge value from the PCO field in the activate context request and communicate it to terminal equipment as an authentication challenge message.
communicates an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates to the SGSN, the create context response being communicated to the mobile terminal in form of the activate context response, and wherein the mobile terminal is operable to extract a challenge value from the PCO field in the activate context request and communicate it to terminal equipment as an authentication challenge message.
12. The apparatus of Claim 8, wherein a PPP
negotiation begins between the GGSN and the LNS in order to establish the communications tunnel, the LNS
recognizing the authentication protocol to use based on the PPP negotiation.
negotiation begins between the GGSN and the LNS in order to establish the communications tunnel, the LNS
recognizing the authentication protocol to use based on the PPP negotiation.
13. A method for executing end to end authentication in a network environment, comprising:
initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS);
communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS;
receiving an activate context response generated by the LNS from the GGSN; and calculating an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS);
communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS;
receiving an activate context response generated by the LNS from the GGSN; and calculating an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
14. The method of Claim 13, further comprising:
communicating a configure request to a serving GPRS
support node (SGSN) in order to establish the communication session.
communicating a configure request to a serving GPRS
support node (SGSN) in order to establish the communication session.
15. The method of Claim 13, further comprising:
initiating a point to point protocol (PPP) negotiation, wherein a first stage of the PPP negotiation is associated with selecting which authentication protocol is to be used.
initiating a point to point protocol (PPP) negotiation, wherein a first stage of the PPP negotiation is associated with selecting which authentication protocol is to be used.
16. The method of Claim 13, further comprising:
receiving an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates, the create context response being communicated in form of the activate context response;
extracting a challenge value from the PCO field in the activate context request; and communicating the challenge value as an authentication challenge message.
receiving an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates, the create context response being communicated in form of the activate context response;
extracting a challenge value from the PCO field in the activate context request; and communicating the challenge value as an authentication challenge message.
17. A system for executing end to end authentication in a network environment, comprising:
means for initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS);
means for communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS;
means for receiving an activate context response generated by the LNS from the GGSN; and means for calculating an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
means for initiating a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS);
means for communicating an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS;
means for receiving an activate context response generated by the LNS from the GGSN; and means for calculating an authentication response by using a stored secret value and a challenge value which is provided in the activate context response, the authentication response being used to establish a communication session associated with the mobile terminal and the LNS.
18. The system of Claim 17, further comprising:
means for communicating a configure request to a serving GPRS support node (SGSN) in order to establish the communication session.
means for communicating a configure request to a serving GPRS support node (SGSN) in order to establish the communication session.
19. The system of Claim 17, further comprising:
means for initiating a point to point protocol (PPP) negotiation, wherein a first stage of the PPP negotiation is associated with selecting which authentication protocol is to be used.
means for initiating a point to point protocol (PPP) negotiation, wherein a first stage of the PPP negotiation is associated with selecting which authentication protocol is to be used.
20. The system of Claim 17, further comprising:
means for receiving an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates, the create context response being communicated in form of the activate context response;
means for extracting a challenge value from the PCO
field in the activate context request; and means for communicating the challenge value as an authentication challenge message.
means for receiving an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates, the create context response being communicated in form of the activate context response;
means for extracting a challenge value from the PCO
field in the activate context request; and means for communicating the challenge value as an authentication challenge message.
21. A computer readable medium having stored thereon instructions for executing end to end authentication in a network environment, the instructions when executed by a processor operable to:
initiate a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS);
communicate an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN
being operable to communicate an activate context response that may be received by the mobile terminal; and calculate an authentication response by using a secret value and a challenge value which is provided by the GGSN, the authentication response being used to establish a communication session associated with the mobile terminal.
initiate a communications tunnel with a layer two tunnel protocol (L2TP) network server (LNS);
communicate an activate context request that includes an authentication protocol in a protocol configuration option (PCO) field, the activate context request being received by a gateway general packet radio service (GPRS) support node (GGSN) that initiates a link control protocol (LCP) negotiation with the LNS, the GGSN
being operable to communicate an activate context response that may be received by the mobile terminal; and calculate an authentication response by using a secret value and a challenge value which is provided by the GGSN, the authentication response being used to establish a communication session associated with the mobile terminal.
22. The computer readable medium of Claim 21, wherein the instructions are further operable to:
communicate a configure request to a serving GPRS
support node (SGSN) in order to establish the communication session.
communicate a configure request to a serving GPRS
support node (SGSN) in order to establish the communication session.
23. The computer readable medium of Claim 21, wherein the instructions are further operable to:
initiate a point to point protocol (PPP) negotiation, wherein a first stage of the PPP negotiation is associated with selecting which authentication protocol is to be used.
initiate a point to point protocol (PPP) negotiation, wherein a first stage of the PPP negotiation is associated with selecting which authentication protocol is to be used.
24. The computer readable medium of Claim 21, wherein the instructions are further operable to:
receive an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates, the create context response being communicated in form of the activate context response; and communicate a challenge value as an authentication challenge message.
receive an authentication challenge value that is positioned in the PCO field of a create context response that the GGSN communicates, the create context response being communicated in form of the activate context response; and communicate a challenge value as an authentication challenge message.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/443,980 US7024687B2 (en) | 2003-05-21 | 2003-05-21 | System and method for providing end to end authentication in a network environment |
| US10/443,980 | 2003-05-21 | ||
| PCT/US2004/013392 WO2004107098A2 (en) | 2003-05-21 | 2004-04-29 | System and method for providing end to end authentication in a network environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2521510A1 CA2521510A1 (en) | 2004-12-09 |
| CA2521510C true CA2521510C (en) | 2011-04-05 |
Family
ID=33450540
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2521510A Expired - Fee Related CA2521510C (en) | 2003-05-21 | 2004-04-29 | System and method for providing end to end authentication in a network environment |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7024687B2 (en) |
| EP (1) | EP1625692B1 (en) |
| CN (1) | CN1781278B (en) |
| AU (1) | AU2004244187B2 (en) |
| CA (1) | CA2521510C (en) |
| WO (1) | WO2004107098A2 (en) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8051168B1 (en) * | 2001-06-19 | 2011-11-01 | Microstrategy, Incorporated | Method and system for security and user account integration by reporting systems with remote repositories |
| KR100438431B1 (en) * | 2002-02-23 | 2004-07-03 | 삼성전자주식회사 | Security system for virtual private network service access in communication network and method thereof |
| KR20050090902A (en) * | 2004-03-10 | 2005-09-14 | 삼성전자주식회사 | The method of vpn service about pdp type in wcdma |
| US20060168241A1 (en) * | 2004-11-24 | 2006-07-27 | Puthiyandyil Sanil K | Redundant L2TP end points |
| US8504700B2 (en) | 2004-12-06 | 2013-08-06 | Samsung Electronics Co., Ltd. | Method, apparatus, and system for negotiating a session between an access terminal and an access network in a high rate packet data system |
| US20060165093A1 (en) * | 2005-01-27 | 2006-07-27 | Utstarcom, Inc. | Method and apparatus to support multi-stack hang time usage and multi-stack accounting |
| TWI262683B (en) * | 2005-02-04 | 2006-09-21 | Ind Tech Res Inst | A method, a wireless server, a mobile device, and a system for handing over, from a wireless server to another wireless server, in a connection between a mobile device in a foreign intranet network, and an intranet network |
| US8369357B2 (en) | 2006-02-28 | 2013-02-05 | Cisco Technology, Inc. | System and method for providing simultaneous handling of layer-2 and layer-3 mobility in an internet protocol network environment |
| CN101496387B (en) | 2006-03-06 | 2012-09-05 | 思科技术公司 | System and method for access authentication in a mobile wireless network |
| US7715562B2 (en) * | 2006-03-06 | 2010-05-11 | Cisco Technology, Inc. | System and method for access authentication in a mobile wireless network |
| US8375430B2 (en) * | 2006-06-27 | 2013-02-12 | Intel Corporation | Roaming secure authenticated network access method and apparatus |
| US7782824B2 (en) * | 2006-07-20 | 2010-08-24 | Cisco Technology, Inc. | Method and system for handling a mobile endpoint in a wireless network |
| CN101316205B (en) * | 2007-05-28 | 2011-08-10 | 华为技术有限公司 | Method for triggering safety tunnel establishment and device thereof |
| US20090328147A1 (en) * | 2008-06-27 | 2009-12-31 | Microsoft Corporation | Eap based capability negotiation and facilitation for tunneling eap methods |
| CN101867990A (en) * | 2010-04-29 | 2010-10-20 | 顾翠红 | Electrical equipment wireless control network with priority level |
| US8464335B1 (en) * | 2011-03-18 | 2013-06-11 | Zscaler, Inc. | Distributed, multi-tenant virtual private network cloud systems and methods for mobile security and policy enforcement |
| CN102571524B (en) * | 2012-02-10 | 2015-01-07 | 浙江宇视科技有限公司 | Method for traversing and assisting to transverse network isolation equipment in IP (Internet Protocol) monitoring system and node |
| EP2879461B1 (en) * | 2012-08-02 | 2019-01-09 | Huawei Technologies Co., Ltd. | Protocol processing method under control and data forwarding decoupling |
| EP3104563B1 (en) * | 2015-06-10 | 2019-10-16 | Nokia Solutions and Networks GmbH & Co. KG | Sdn security |
| CN106961371B (en) * | 2016-01-11 | 2019-10-15 | 启碁科技股份有限公司 | Package turns the method passed and package turns to pass device |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6233232B1 (en) * | 1997-04-08 | 2001-05-15 | 3Com Corporation | Supporting multilink connections across multiple network access servers |
| US6160808A (en) * | 1997-12-18 | 2000-12-12 | 3Com Corporation | Technique for transmitting incoming multi-link point-to-point (PPP) packet traffic over multiple outgoing links in a multi-link bundle |
| DE69833929T2 (en) * | 1998-04-10 | 2007-03-15 | Sun Microsystems, Inc., Mountain View | Network access authentication system |
| US6496491B2 (en) * | 1998-05-08 | 2002-12-17 | Lucent Technologies Inc. | Mobile point-to-point protocol |
| US6449272B1 (en) * | 1998-05-08 | 2002-09-10 | Lucent Technologies Inc. | Multi-hop point-to-point protocol |
| US6282193B1 (en) * | 1998-08-21 | 2001-08-28 | Sonus Networks | Apparatus and method for a remote access server |
| US6470453B1 (en) * | 1998-09-17 | 2002-10-22 | Cisco Technology, Inc. | Validating connections to a network system |
| US6445682B1 (en) * | 1998-10-06 | 2002-09-03 | Vertical Networks, Inc. | Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet buses and methods for performing telephony and data functions using the same |
| JP3541873B2 (en) * | 1998-12-24 | 2004-07-14 | 船井電機株式会社 | Magnetic recording device |
| US6452920B1 (en) * | 1998-12-30 | 2002-09-17 | Telefonaktiebolaget Lm Ericsson | Mobile terminating L2TP using mobile IP data |
| US6654808B1 (en) * | 1999-04-02 | 2003-11-25 | Lucent Technologies Inc. | Proving quality of service in layer two tunneling protocol networks |
| EP1133132B1 (en) * | 2000-03-10 | 2007-07-25 | Alcatel Lucent | Method to perfom end-to-end authentication, and related customer premises network termination and access network server |
| US6687252B1 (en) * | 2000-06-12 | 2004-02-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic IP address allocation system and method |
| SE0004178D0 (en) * | 2000-11-14 | 2000-11-14 | Ericsson Telefon Ab L M | Network requested packet data protocol context activation |
| US6765881B1 (en) * | 2000-12-06 | 2004-07-20 | Covad Communications Group, Inc. | Virtual L2TP/VPN tunnel network and spanning tree-based method for discovery of L2TP/VPN tunnels and other layer-2 services |
| US6999435B2 (en) * | 2001-03-29 | 2006-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, system and node for providing enhanced mobility in simple IP telecommunication networks when performing L2TP tunneling |
| US7240366B2 (en) * | 2002-05-17 | 2007-07-03 | Microsoft Corporation | End-to-end authentication of session initiation protocol messages using certificates |
-
2003
- 2003-05-21 US US10/443,980 patent/US7024687B2/en not_active Expired - Lifetime
-
2004
- 2004-04-29 CA CA2521510A patent/CA2521510C/en not_active Expired - Fee Related
- 2004-04-29 WO PCT/US2004/013392 patent/WO2004107098A2/en active Application Filing
- 2004-04-29 CN CN2004800110947A patent/CN1781278B/en not_active Expired - Fee Related
- 2004-04-29 EP EP04785624.0A patent/EP1625692B1/en not_active Expired - Lifetime
- 2004-04-29 AU AU2004244187A patent/AU2004244187B2/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004107098A2 (en) | 2004-12-09 |
| EP1625692A4 (en) | 2011-04-20 |
| WO2004107098A3 (en) | 2005-02-10 |
| US7024687B2 (en) | 2006-04-04 |
| CN1781278A (en) | 2006-05-31 |
| AU2004244187B2 (en) | 2010-02-04 |
| CA2521510A1 (en) | 2004-12-09 |
| AU2004244187A1 (en) | 2004-12-09 |
| EP1625692A2 (en) | 2006-02-15 |
| CN1781278B (en) | 2010-09-01 |
| US20040236947A1 (en) | 2004-11-25 |
| EP1625692B1 (en) | 2016-09-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2521510C (en) | System and method for providing end to end authentication in a network environment | |
| US8091121B2 (en) | Method and apparatus for supporting different authentication credentials | |
| Prasad et al. | 3GPP 5G security | |
| EP1450571B1 (en) | Method and arrangement for configuring communication session in a communications network | |
| EP1330073B1 (en) | Method and apparatus for access control of a wireless terminal device in a communications network | |
| EP2939391B1 (en) | Method and system for secure network access | |
| US20060002426A1 (en) | Header compression negotiation in a telecommunications network using the protocol for carrying authentication for network access (PANA) | |
| US9332435B2 (en) | Device, system and method using EAP for external authentication | |
| JP2006523412A (en) | Automatic configuration of client terminals in public hot spots | |
| JP2007535240A (en) | Improved subscriber authentication for unlicensed mobile connection signaling | |
| US10277586B1 (en) | Mobile authentication with URL-redirect | |
| WO2006024969A1 (en) | Wireless local area network authentication method | |
| CN101867476A (en) | 3G virtual private dialing network user safety authentication method and device thereof | |
| US20130019097A1 (en) | Method and Apparatus for Securing Communication Between a Mobile Node and a Network | |
| JP2013168974A5 (en) | ||
| US8312530B2 (en) | System and method for providing security in a network environment using accounting information | |
| Lunde et al. | Using SIM for strong end-to-end Application Authentication | |
| CN114765805A (en) | Communication method, network equipment, base station and computer readable storage medium | |
| KR100388062B1 (en) | Method of CHAP Authentication for ISP Mobile Subscriber in 3rd Generation GPRS Network | |
| JP2004201087A (en) | Method for dial-up connecting by portable telephone | |
| Xenakis et al. | Alternative Schemes for Dynamic Secure VPN Deployment in UMTS | |
| Chamuczynski et al. | Performance study of PANA pre-authentication for interdomain handover | |
| Prasad et al. | 2 Evolution of the Trust Model | |
| CN104618259A (en) | Method and device for limiting speed of terminal device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20180430 |