US7197763B2 - Authentication in a communication system - Google Patents

Authentication in a communication system Download PDF

Info

Publication number
US7197763B2
US7197763B2 US10/987,509 US98750904A US7197763B2 US 7197763 B2 US7197763 B2 US 7197763B2 US 98750904 A US98750904 A US 98750904A US 7197763 B2 US7197763 B2 US 7197763B2
Authority
US
United States
Prior art keywords
authentication
format
challenge
packet data
voice communication
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, expires
Application number
US10/987,509
Other versions
US20050090232A1 (en
Inventor
Raymond T. Hsu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Priority to US10/987,509 priority Critical patent/US7197763B2/en
Publication of US20050090232A1 publication Critical patent/US20050090232A1/en
Application granted granted Critical
Publication of US7197763B2 publication Critical patent/US7197763B2/en
Adjusted expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/162Implementing security features at a particular protocol layer at the data link layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys

Definitions

  • the present relates to authentication in a communication system, and more specifically to mechanisms for common authentication and session key distribution using a common format, such as Cellular Authentication Voice Encryption (CAVE) for both voice and data communications.
  • CAVE Cellular Authentication Voice Encryption
  • a common authentication mechanism for cellular telephone systems is referred to as Cellular Authentication Voice Encryption or “CAVE.”
  • Other mechanisms for authentication are implemented in data systems, such as the mechanism referred to as Authentication and Key Agreement or “AKA.”
  • AKA Authentication and Key Agreement
  • FIG. 1 is an architectural illustration of the extension of the Extensible Authentication Protocol (EAP) to support a Cellular Authentication Voice Encryption (CAVE) algorithm.
  • EAP Extensible Authentication Protocol
  • CAVE Cellular Authentication Voice Encryption
  • FIG. 2 is a communication system.
  • FIG. 3 is a timing diagram of authentication processing in a communication system.
  • FIG. 4A and FIG. 4B are fields in an EAP format.
  • FIG. 5A and FIG. 5B are examples of authentication processing in a system wherein an EAP format supports the CAVE algorithm.
  • FIG. 6 is a flow diagram of authentication processing at an authenticator.
  • FIG. 7 is a flow diagram of authentication processing at a mobile station.
  • FIG. 8 is a wireless device supporting an extended EAP format that supports the CAVE algorithm.
  • An HDR subscriber station referred to herein as an access terminal (AT) may be mobile or stationary, and may communicate with one or more HDR base stations, referred to herein as modem pool transceivers (MPTs).
  • An access terminal transmits and receives data packets through one or more modem pool transceivers to an HDR base station controller, referred to herein as a modem pool controller (MPC).
  • Modem pool transceivers and modem pool controllers are parts of a network called an access network.
  • An access network transports data packets between multiple access terminals.
  • the access network may be further connected to additional networks outside the access network, such as a corporate intranet or the Internet, and may transport data packets between each access terminal and such outside networks.
  • An access terminal that has established an active traffic channel connection with one or more modem pool transceivers is called an active access terminal, and is said to be in a traffic state.
  • An access terminal that is in the process of establishing an active traffic channel connection with one or more modem pool transceivers is said to be in a connection setup state.
  • An access terminal may be any data device that communicates through a wireless channel or through a wired channel, for example using fiber optic or coaxial cables.
  • An access terminal may further be any of a number of types of devices including but not limited to PC card, compact flash, external or internal modem, or wireless or wireline phone.
  • the communication link through which the access terminal sends signals to the modem pool transceiver is called a reverse link.
  • the communication link through which a modem pool transceiver sends signals to an access terminal is called a forward link.
  • Authentication is the process of proving the identity of an individual or application in a communication. Such identification allows the service provider to verify the entity as a valid user and also to verify the user for the specific services requested. Authentication and authorization actually have very specific meanings, though the two names are often used interchangeably, and in practice are often not clearly distinguished.
  • Authentication is the process where a user establishes a right to an identity—in essence, the right to use a name.
  • a name or identity has attributes associated with it. Attributes may be bound closely to a name (for example, in a certificate payload) or they may be stored in a directory or other database under a key corresponding to the name. Attributes may change over time.
  • Authorization is the process of determining whether an identity (plus a set of attributes associated with that identity) is permitted to perform some action, such as accessing a resource. Note that permission to perform an action does not guarantee that the action can be performed. Note that authentication and authorization decisions can be made at different points, by different entities.
  • the authentication feature is a network capability that allows cellular networks to validate the identity of wireless device, thereby reducing unauthorized use of cellular networks.
  • the process is transparent to subscribers. Customers are not required to do anything to authenticate the identity of their phones when they make a call.
  • Authentication typically involves a cryptographic scheme, wherein the service provider and the user have some shared information and some private information.
  • the shared information is typically referred to as a “shared secret.”
  • the authentication key is a secret value that is unique to each individual cellular phone. It is registered with the cellular service provider and stored in the phone and Authentication Center (AC).
  • the A-key is programmed into the phone by the manufacturer. It can also be entered manually by the user, from the wireless device menu, or by a special terminal at the point of sale.
  • the wireless device and the AC must have the same A-key to produce the same calculations.
  • the primary function of the A-key is to be used as a parameter to calculate the shared secret data (SSD).
  • the SSD is used as an input for authentication calculations in the wireless device and the AC, and is stored in both places. Unlike the A-key, the SSD may be modified over the network.
  • the AC and the wireless device share three elements that go into the calculation of the SSD: 1) the Electronic Serial Number (ESN); 2) the Authentication Key (A-Key); and 3) a RANDom number for Shared Secret Data calculation (RANDSSD).
  • ESN Electronic Serial Number
  • A-Key Authentication Key
  • RANDSSD RANDom number for Shared Secret Data calculation
  • the ESN and RANDSSD are transmitted over the network and over the air interface.
  • the SSD is updated when a device makes its first system access, and periodically thereafter.
  • the result is two separate values, SSD-A and SSD-B.
  • SSD-A is used for authentication.
  • SSD-B is used for encryption and voice privacy.
  • SSD may be shared or not shared between the AC and serving Mobile Switching Center (MSC). If secret data is shared, it means the AC will send it to the serving MSC and the serving MSC must be capable of executing CAVE. If it is not shared, the AC will keep the data and perform authentication.
  • MSC Mobile Switching Center
  • An authentication challenge is a message sent to challenge the identify of the wireless device. Basically, the authentication challenge sends some information, typically random number data, for the user to process. The user then processes the information and sends a response. The response is analyzed for verification of the user.
  • shared secret data a challenge is handled at the serving MSC.
  • non-shared secret data a challenge is handled by the AC.
  • a Home Location Register controls the authentication process by acting as intermediary between the MSC and AC.
  • the serving MSC is set up to support authentication with the mobile's HLR and vice versa.
  • the device initiates the process by notifying the serving MSC if it is capable of authentication, by setting an authorization field in the overhead message train.
  • the serving MSC starts the registration/authentication process with an Authentication Request.
  • the serving MSC By sending the Authentication Request, the serving MSC tells the HLR/AC whether it is capable of doing CAVE calculations.
  • the AC controls which of the serving MSC's as well as device capabilities will be used out of those available.
  • the SSD cannot be shared between the AC and MSC and therefore all authentication processes are performed in the AC.
  • the purpose of the Authentication Request is to authenticate the phone and request SSD.
  • the AUTHREQ contains two parameters for authentication, the AUTHR and RAND parameters.
  • the AC gets the AUTHREQ it uses the RAND and the last known SSD to calculate AUTHR. If it matches the AUTHR sent in the AUTHREQ then authentication is successful.
  • the return result to the AUTHREQ will contain the SSD if it can be shared.
  • the Authentication process consists of a challenge and response dialog. If SSD is shared, the dialog runs between the MSC and the device. If SSD is not shared, the dialog runs between the HLR/AC and the device.
  • the MSC may be capable of either a Unique Challenge, a Global Challenge, or both. Some MSCs are currently not capable of global challenge.
  • the Unique Challenge is a challenge that occurs during call attempts only, because it uses the voice channel. Unique challenge presents an authentication to a single device during call origination and call delivery.
  • the Global Challenge is a challenge that occurs during registration, call origination, and call delivery.
  • the Global challenge presents an authentication challenge to all MSs that are using a particular radio control channel. It is called global challenge because it is broadcast on the radio control channel, and the challenge is used by all phones accessing that control channel.
  • the device responds to a random number provided by the MSC or AC.
  • the device uses the random number and shared secret data stored in the device to calculate a response to the MSC.
  • the MSC also uses the random number and shared secret data to calculate what the response from the device should be. These calculations are done through the CAVE algorithm. If the responses are not the same, service is denied.
  • the challenge process does not increase the amount of time it takes to connect the call. In fact, the call may proceed in some cases, only to be torn down when authentication fails.
  • the CAVE algorithm is commonly used for cellular communications and therefore, is well used and distributed. Alternate algorithms for authentication are also used. Specifically in data communications a variety of algorithms exist of varying complexity and application. To coordinate these mechanisms, the Extensible Authentication Protocol (EAP) has been developed as a general protocol framework that supports multiple authentication and key distribution mechanisms. The EAP is described in “PPP Extensible Authentication Protocol (EAP)” by L. Blunk et al, RFC 2284, published March 1998.
  • EAP Extensible Authentication Protocol
  • EAP AKA Authentication One such mechanism supported by the EAP as defined in “EAP AKA Authentication” by J. Arkko et al., currently an Internet draft, published February 2002, is the AKA algorithm. There is a need therefore to extend EAP to include the cellular algorithm CAVE. This is desirable to provide back compatibility for new systems and networks.
  • the Extensible Authentication Protocol is a general protocol for authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism during link set up and control, but rather postpones this until the authentication procedure begins. This allows the authenticator to request more information before determining the specific authentication mechanism.
  • the authenticator is defined as the end of the link requiring the authentication. The authenticator specifies the authentication protocol to be used in the during link establishment.
  • FIG. 4A illustrates some of the fields assigned according to EAP.
  • the EAP 300 defines a first field CODE field 302 which identifies the type of message.
  • the IDENTIFIER field 304 allows for correlated responses, wherein the challenge will have an identifier associated with it that is also used by the response to the challenge.
  • the LENGTH field 306 gives the length of the EAP request packet.
  • the TYPE field 308 identifies the type of EAP message that is contained in the PAYLOAD field 310 . For example, for AKA authentication, the TYPE field 308 will identify the information as AKA information, and the PAYLOAD field 310 will include an AKA challenge, response, etc.
  • the EAP is extended to support CAVE authentication.
  • an architecture for implementing CAVE using EAP allows the CAVE authentication procedures to be applied directly to voice type systems and any other system that supports CAVE.
  • Each block represents an algorithm or messaging type used according to the architecture of the present embodiment.
  • CAVE 102 applies to both the voice network and the data network.
  • CAVE 102 uses a signaling message 120 to facilitate authentication.
  • CAVE 102 uses the EAP 104 to facilitate authentication.
  • EAP 104 may be implemented with PPP framing format 106 , Internet Protocol (IP) packet format 108 , or consistent with a Remote Authentication Dial-In User Service (RADIUS) message format 110 .
  • RADIUS is an Internet user authentication described in RFC 2138, “Remote Authentication Dial In User Service (RADIUS)” by C. Rigney et al., published April 1997.
  • FIG. 2 illustrates a communication system 200 employing the architecture of one embodiment.
  • the Mobile Station (MS) 202 is in communication with an authenticator 204 .
  • the authenticator initiates authentication of the MS 202 when the MS attempts to access data services 208 (outside of the network 210 ) or data services 206 (within the network 210 ).
  • system 200 may include any number of services both in and out of the network 210 .
  • the authenticator 204 implements the CAVE algorithm using EAP.
  • the call processing is illustrated in FIG. 3 .
  • the authenticator 204 initiates the authentication process with MS 202 .
  • the authenticator 204 first sends a request for identification to MS 202 by sending an EAP-Request/Identity message to the MS 202 .
  • the MS sends an EAP-Response/Identity message containing the International Mobile Subscriber Identity (IMSI) of the MS 202 , or containing an alias name associated with the MS 202 . Since the EAP-Response/Identity message is in clear text, i.e., not yet encrypted data, it is vulnerable to eavesdropping over the air during transmission.
  • IMSI International Mobile Subscriber Identity
  • the MS 202 may desire to provide identity using a known alias name.
  • the authenticator 204 maps the MS 202 alias name to the MS 202 IMSI.
  • An example of an alias name is user@realm (e.g., joe@abc.com).
  • the authenticator 204 determines whether the MS 202 is using CAVE for access authentication. To make such determination, the authenticator 204 sends an “EAP-Request/CAVE-Challenge” message to the MS. The message is sent as an EAP Request message containing a CAVE challenge in the payload. The format for the request is illustrated in FIG. 4B and discussed hereinbelow.
  • the EAP-Request/CAVE-Challenge message contains a challenge, which is a random number generated by the authenticator 204 .
  • the MS 202 then computes an authentication response by applying: 1) secret data; 2) the IMSI of MS 202 ; and 3) the challenge received, as input to the CAVE algorithm. The result is then provided as an “EAP-Response/CAVE-Challenge” message or response to the authenticator 204 .
  • the MS 202 sends the EAP-Response/CAVE-Challenge message to the authenticator 204 , wherein the message contains the authentication response.
  • the message does not necessarily contain the MS 202 identify (e.g., IMSI or alias name) and/or the challenge, because the message will use the same message identifier as the EAP-Request/CAVE-Challenge message sent by the authenticator 204 originally. Via the message identifier, the authenticator 204 may associate the MS 202 authentication response with the MS 202 identity and the challenge.
  • the authenticator 204 then verifies the MS 202 authentication response by comparing it with the expected response.
  • the authenticator 204 may or may not know the MS 202 shared secret. If the authenticator 204 knows, or has knowledge of, the shared secret, the authenticator 204 computes an expected response by using the MS's shared secret, MS's IMSI, and the challenge as input to the CAVE algorithm. If the authenticator 204 does not have the secret, it obtains the expected response from the entity that has the MS 202 shared secret.
  • the MS 202 authentication response is the same as the expected response, the MS 202 passes the authentication, and the authenticator 204 sends the “EAP-Success” message, so indicating, to the MS 202 . If the MS 202 fails the authentication, the authenticator 204 sends an “EAP-Failure” message (not shown), indicating the authenticator 204 was unable to authenticate the MS 202 for the desired access, to the MS 202 .
  • FIG. 4B illustrates the extension of the EAP for application of CAVE authentication procedures.
  • the TYPE field 308 is extended to TYPE filed 312 which includes a CAVE option.
  • the associated PAYLOAD field 314 is then adapted to include a CAVE message, e.g., CAVE challenge or CAVE response.
  • the EAP may be used with CAVE authentication procedures.
  • the EAP will be the transport mechanism for the negotiations involved in the CAVE authentication.
  • CAVE specifies the messages and the order of messages required for authentication.
  • CAVE further specifies the authentication procedures performed at the MS 202 and the authenticator 204 , as well as the information and variables needed for such authentication.
  • the EAP specifies how the information and variables, messages, etc. to implement CAVE authentication are communicated between the MS 202 and the authenticator 204 .
  • FIGS. 5A and 5B illustrate various scenarios for implementation of CAVE with EAP.
  • the EAP request message from the authenticator 204 is made as a CAVE challenge.
  • the TYPE field 312 identifies the request as a CAVE message
  • the PAYLOAD field 314 contains the CAVE message, which in this case is a CAVE challenge.
  • the MS 202 receives the CAVE challenge via the EAP request message, processes the received information contained in the PAYLOAD field 314 according to the CAVE procedures, and provides the result as a CAVE response back to the authenticator 204 via an EAP response message.
  • the EAP request message from the authenticator 204 is made according to another authentication procedure referred to as the “MD5-Challenge,” which is also known as the Challenge Handshake Authentication Protocol (CHAP).
  • the MS 202 receives the EAP request message but does not support the MD 5 -Challenge procedures and therefore replies with a Negative Acknowledge message as an EAP response message.
  • the messages sent between the authenticator 204 and the MS 202 are EAP messages.
  • the authenticator 204 receives the NAK via the EAP response message and attempts to authenticate using another type of algorithm.
  • the authenticator 204 may try any number of algorithm types as supported by the EAP format. In this case, the authenticator 204 sends a CAVE challenge in an EAP request message.
  • the MS 202 receives the information, calculates a response, and responds with a CAVE response in an EAP response message. In this way, the authenticator 204 is able to determine the capability of the MS 202 and respond accordingly.
  • FIG. 6 is a flow diagram of authentication procedures according to one embodiment at the authenticator 204 .
  • the process 400 begins when the authenticator 204 receives a request for a given service at step 402 .
  • the request for service may for data services, voice services, or a combination thereof.
  • the authenticator 204 determines if the communication is voice or data at decision diamond 404 .
  • a combination type service such as Voice over IP (VoIP) is typically treated as a data communication.
  • VoIP Voice over IP
  • processing continues to step 406 to send an EAP request for identification of the MS 202 .
  • the authenticator 204 receives a response from the MS 202 at step 408 .
  • the authenticator 204 sends a CAVE challenge via an EAP request message at step 410 .
  • the authenticator 204 determines the status of the authentication procedure at decision diamond 416 . If the authentication of MS 202 passed, the authenticator 204 authorizes the service at step 418 . If the authentication of MS 202 fails, then the authenticator 204 notifies the MS 202 of a failure to authenticate at step 420 .
  • the authenticator 204 For voice communications, from decision diamond 404 the authenticator 204 sends a CAVE challenge as a signaling message at step 412 . The authenticator 204 receives a CAVE response at step 414 . The processing then continues to decision diamond 416 to determine the status of the authentication.
  • FIG. 7 is a flow diagram of an authentication procedure at the MS 202 .
  • the MS 202 sends a request for data services at step 502 .
  • the MS 202 receives a request for identification in an EAP request message at 504 .
  • the MS 202 then sends identification information in an EAP response message at step 506 .
  • a challenge is received via an EAP request message at step 508 .
  • the MS 202 determines the format of the challenge. If the format is according to the CAVE algorithm, then processing continues to step 512 ; else processing continues to step 518 to send a NAK message via an EAP response. From step 518 processing returns to step 508 to await another challenge.
  • processing at step 512 computes a response as described hereinabove and consistent with CAVE procedures.
  • the MS 202 sends the response as an EAP response message at step 514 .
  • the MS receives confirmation of the authentication at step 516 and the authentication procedure is complete.
  • the device 600 includes receive circuitry 602 and transmit circuitry 604 for receiving transmissions and sending transmissions, respectively.
  • the receive circuitry 602 and the transmit circuitry 604 are both coupled to a communication bus 612 .
  • the device 600 also includes a Central Processing Unit (CPU) 606 for controlling operations within the device 600 .
  • the CPU 606 is responsive to computer-readable instructions stored in memory storage devices within the device 600 . Two such storage devices are illustrated as storing the CAVE procedure 608 and the EAP procedure 610 . Note that alternate embodiments may implement the procedure in hardware, software, firmware, or a combination thereof.
  • the CPU 606 is then responsive to authentication processing instructions from the CAVE procedure 608 .
  • the CPU 606 places the CAVE procedure 608 messages into an EAP format in response to EAP procedure 610 .
  • the CPU 606 further processes received EAP messages to extract the CAVE messages therefrom.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium.
  • the storage medium may be integral to the processor.
  • the processor and the storage medium may reside in an ASIC.
  • the ASIC may reside in a user terminal.
  • the processor and the storage medium may reside as discrete components in a user terminal.

Abstract

Method and apparatus for providing Cellular Authentication Voice Encryption (CAVE) messages in an Extensible Authentication Protocol (EAP) format. The CAVE messages are sent via an EAP transport mechanism. The Mobile Station (MS) is able to use a common authentication mechanism for other technologies.

Description

REFERENCE TO CO-PENDING APPLICATIONS FOR PATENT
This application is a Continuation Application of U.S. application Ser. No. 10/177,088, filed on Jun. 20, 2002 now abandoned which is entitled “Authentication in a Communication System,” and currently assigned to the assignee of the present application.
The present Application for Patent is also related to the following co-pending Applications for Patent:
  • “Inter-working Function for a Communication System,” by Raymond Hsu, filed on Jun. 20, 2002 with application Ser. No. 10/176,562, assigned to the assignee hereof and hereby expressly incorporated by reference; and
  • “Key Generation in a Communication System,” by Raymond Hsu, filed on Jun. 20, 2002 with application Ser. No. 10/177,017; assigned to the assignee hereof and hereby expressly incorporated by reference.
BACKGROUND
1. Field
The present relates to authentication in a communication system, and more specifically to mechanisms for common authentication and session key distribution using a common format, such as Cellular Authentication Voice Encryption (CAVE) for both voice and data communications.
2. Background
As communication systems and infrastructures expand to provide a variety of voice and data services, the various protocols and authentication procedures incur added complexity, additional use of resources and time delays at set up. A common authentication mechanism for cellular telephone systems is referred to as Cellular Authentication Voice Encryption or “CAVE.” Other mechanisms for authentication are implemented in data systems, such as the mechanism referred to as Authentication and Key Agreement or “AKA.” When communication systems are expanded to incorporate other services there may be multiple authentication procedures used. There is therefore a need in the art to provide a common format for authentication and set up.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an architectural illustration of the extension of the Extensible Authentication Protocol (EAP) to support a Cellular Authentication Voice Encryption (CAVE) algorithm.
FIG. 2 is a communication system.
FIG. 3 is a timing diagram of authentication processing in a communication system.
FIG. 4A and FIG. 4B are fields in an EAP format.
FIG. 5A and FIG. 5B are examples of authentication processing in a system wherein an EAP format supports the CAVE algorithm.
FIG. 6 is a flow diagram of authentication processing at an authenticator.
FIG. 7 is a flow diagram of authentication processing at a mobile station.
FIG. 8 is a wireless device supporting an extended EAP format that supports the CAVE algorithm.
DETAILED DESCRIPTION
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.
An HDR subscriber station, referred to herein as an access terminal (AT), may be mobile or stationary, and may communicate with one or more HDR base stations, referred to herein as modem pool transceivers (MPTs). An access terminal transmits and receives data packets through one or more modem pool transceivers to an HDR base station controller, referred to herein as a modem pool controller (MPC). Modem pool transceivers and modem pool controllers are parts of a network called an access network. An access network transports data packets between multiple access terminals. The access network may be further connected to additional networks outside the access network, such as a corporate intranet or the Internet, and may transport data packets between each access terminal and such outside networks. An access terminal that has established an active traffic channel connection with one or more modem pool transceivers is called an active access terminal, and is said to be in a traffic state. An access terminal that is in the process of establishing an active traffic channel connection with one or more modem pool transceivers is said to be in a connection setup state. An access terminal may be any data device that communicates through a wireless channel or through a wired channel, for example using fiber optic or coaxial cables. An access terminal may further be any of a number of types of devices including but not limited to PC card, compact flash, external or internal modem, or wireless or wireline phone. The communication link through which the access terminal sends signals to the modem pool transceiver is called a reverse link. The communication link through which a modem pool transceiver sends signals to an access terminal is called a forward link.
Authentication is the process of proving the identity of an individual or application in a communication. Such identification allows the service provider to verify the entity as a valid user and also to verify the user for the specific services requested. Authentication and authorization actually have very specific meanings, though the two names are often used interchangeably, and in practice are often not clearly distinguished.
Authentication is the process where a user establishes a right to an identity—in essence, the right to use a name. There are a large number of techniques that may be used to authenticate a user—passwords, biometric techniques, smart cards, certificates.
A name or identity has attributes associated with it. Attributes may be bound closely to a name (for example, in a certificate payload) or they may be stored in a directory or other database under a key corresponding to the name. Attributes may change over time.
Authorization is the process of determining whether an identity (plus a set of attributes associated with that identity) is permitted to perform some action, such as accessing a resource. Note that permission to perform an action does not guarantee that the action can be performed. Note that authentication and authorization decisions can be made at different points, by different entities.
In a cellular network, the authentication feature is a network capability that allows cellular networks to validate the identity of wireless device, thereby reducing unauthorized use of cellular networks. The process is transparent to subscribers. Customers are not required to do anything to authenticate the identity of their phones when they make a call.
Authentication typically involves a cryptographic scheme, wherein the service provider and the user have some shared information and some private information. The shared information is typically referred to as a “shared secret.”
The A-Key
The authentication key (A-key) is a secret value that is unique to each individual cellular phone. It is registered with the cellular service provider and stored in the phone and Authentication Center (AC). The A-key is programmed into the phone by the manufacturer. It can also be entered manually by the user, from the wireless device menu, or by a special terminal at the point of sale.
The wireless device and the AC must have the same A-key to produce the same calculations. The primary function of the A-key is to be used as a parameter to calculate the shared secret data (SSD).
The Shared Secret Data (SSD)
The SSD is used as an input for authentication calculations in the wireless device and the AC, and is stored in both places. Unlike the A-key, the SSD may be modified over the network. The AC and the wireless device share three elements that go into the calculation of the SSD: 1) the Electronic Serial Number (ESN); 2) the Authentication Key (A-Key); and 3) a RANDom number for Shared Secret Data calculation (RANDSSD).
The ESN and RANDSSD are transmitted over the network and over the air interface. The SSD is updated when a device makes its first system access, and periodically thereafter. When the SSD is calculated, the result is two separate values, SSD-A and SSD-B. SSD-A is used for authentication. SSD-B is used for encryption and voice privacy.
Depending on the capabilities of the serving system, SSD may be shared or not shared between the AC and serving Mobile Switching Center (MSC). If secret data is shared, it means the AC will send it to the serving MSC and the serving MSC must be capable of executing CAVE. If it is not shared, the AC will keep the data and perform authentication.
The type of sharing affects how an authentication challenge is conducted. An authentication challenge is a message sent to challenge the identify of the wireless device. Basically, the authentication challenge sends some information, typically random number data, for the user to process. The user then processes the information and sends a response. The response is analyzed for verification of the user. With shared secret data, a challenge is handled at the serving MSC. With non-shared secret data, a challenge is handled by the AC. By sharing secret data, the system may minimize the amount of traffic sent and allow challenges to happen more quickly at the serving switch.
Authentication Procedures
In a given system, a Home Location Register (HLR) controls the authentication process by acting as intermediary between the MSC and AC. The serving MSC is set up to support authentication with the mobile's HLR and vice versa.
The device initiates the process by notifying the serving MSC if it is capable of authentication, by setting an authorization field in the overhead message train. In response, the serving MSC starts the registration/authentication process with an Authentication Request.
By sending the Authentication Request, the serving MSC tells the HLR/AC whether it is capable of doing CAVE calculations. The AC controls which of the serving MSC's as well as device capabilities will be used out of those available. When the serving MSC does not have CAVE capability, the SSD cannot be shared between the AC and MSC and therefore all authentication processes are performed in the AC.
The purpose of the Authentication Request (AUTHREQ) is to authenticate the phone and request SSD. The AUTHREQ contains two parameters for authentication, the AUTHR and RAND parameters. When the AC gets the AUTHREQ, it uses the RAND and the last known SSD to calculate AUTHR. If it matches the AUTHR sent in the AUTHREQ then authentication is successful. The return result to the AUTHREQ will contain the SSD if it can be shared.
The Challenge
The Authentication process consists of a challenge and response dialog. If SSD is shared, the dialog runs between the MSC and the device. If SSD is not shared, the dialog runs between the HLR/AC and the device. Depending on the switch type, the MSC may be capable of either a Unique Challenge, a Global Challenge, or both. Some MSCs are currently not capable of global challenge. The Unique Challenge is a challenge that occurs during call attempts only, because it uses the voice channel. Unique challenge presents an authentication to a single device during call origination and call delivery. The Global Challenge is a challenge that occurs during registration, call origination, and call delivery. The Global challenge presents an authentication challenge to all MSs that are using a particular radio control channel. It is called global challenge because it is broadcast on the radio control channel, and the challenge is used by all phones accessing that control channel.
During a challenge, the device responds to a random number provided by the MSC or AC. The device uses the random number and shared secret data stored in the device to calculate a response to the MSC. The MSC also uses the random number and shared secret data to calculate what the response from the device should be. These calculations are done through the CAVE algorithm. If the responses are not the same, service is denied. The challenge process does not increase the amount of time it takes to connect the call. In fact, the call may proceed in some cases, only to be torn down when authentication fails.
As stated hereinabove, the CAVE algorithm is commonly used for cellular communications and therefore, is well used and distributed. Alternate algorithms for authentication are also used. Specifically in data communications a variety of algorithms exist of varying complexity and application. To coordinate these mechanisms, the Extensible Authentication Protocol (EAP) has been developed as a general protocol framework that supports multiple authentication and key distribution mechanisms. The EAP is described in “PPP Extensible Authentication Protocol (EAP)” by L. Blunk et al, RFC 2284, published March 1998.
One such mechanism supported by the EAP as defined in “EAP AKA Authentication” by J. Arkko et al., currently an Internet draft, published February 2002, is the AKA algorithm. There is a need therefore to extend EAP to include the cellular algorithm CAVE. This is desirable to provide back compatibility for new systems and networks.
EAP
The Extensible Authentication Protocol (EAP) is a general protocol for authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism during link set up and control, but rather postpones this until the authentication procedure begins. This allows the authenticator to request more information before determining the specific authentication mechanism. The authenticator is defined as the end of the link requiring the authentication. The authenticator specifies the authentication protocol to be used in the during link establishment.
FIG. 4A illustrates some of the fields assigned according to EAP. As illustrated, the EAP 300 defines a first field CODE field 302 which identifies the type of message. The IDENTIFIER field 304 allows for correlated responses, wherein the challenge will have an identifier associated with it that is also used by the response to the challenge. The LENGTH field 306 gives the length of the EAP request packet. The TYPE field 308 identifies the type of EAP message that is contained in the PAYLOAD field 310. For example, for AKA authentication, the TYPE field 308 will identify the information as AKA information, and the PAYLOAD field 310 will include an AKA challenge, response, etc.
CAVE Application of EAP
According to one embodiment of the present invention, the EAP is extended to support CAVE authentication. As illustrated in FIG. 1, an architecture for implementing CAVE using EAP allows the CAVE authentication procedures to be applied directly to voice type systems and any other system that supports CAVE. Each block represents an algorithm or messaging type used according to the architecture of the present embodiment. CAVE 102 applies to both the voice network and the data network. For voice communications, CAVE 102 uses a signaling message 120 to facilitate authentication. For data communications, CAVE 102 uses the EAP 104 to facilitate authentication. EAP 104 may be implemented with PPP framing format 106, Internet Protocol (IP) packet format 108, or consistent with a Remote Authentication Dial-In User Service (RADIUS) message format 110. RADIUS is an Internet user authentication described in RFC 2138, “Remote Authentication Dial In User Service (RADIUS)” by C. Rigney et al., published April 1997.
FIG. 2 illustrates a communication system 200 employing the architecture of one embodiment. The Mobile Station (MS) 202 is in communication with an authenticator 204. The authenticator initiates authentication of the MS 202 when the MS attempts to access data services 208 (outside of the network 210) or data services 206 (within the network 210). Note that system 200 may include any number of services both in and out of the network 210. The authenticator 204 implements the CAVE algorithm using EAP. The call processing is illustrated in FIG. 3.
As illustrated in FIG. 3, the authenticator 204 initiates the authentication process with MS 202. The authenticator 204 first sends a request for identification to MS 202 by sending an EAP-Request/Identity message to the MS 202. In response, the MS sends an EAP-Response/Identity message containing the International Mobile Subscriber Identity (IMSI) of the MS 202, or containing an alias name associated with the MS 202. Since the EAP-Response/Identity message is in clear text, i.e., not yet encrypted data, it is vulnerable to eavesdropping over the air during transmission. Since IMSI is considered to be sensitive information to the MS 202, the MS 202 may desire to provide identity using a known alias name. In this case, the authenticator 204 maps the MS 202 alias name to the MS 202 IMSI. An example of an alias name is user@realm (e.g., joe@abc.com).
Based on the MS 202 IMSI, the authenticator 204 determines whether the MS 202 is using CAVE for access authentication. To make such determination, the authenticator 204 sends an “EAP-Request/CAVE-Challenge” message to the MS. The message is sent as an EAP Request message containing a CAVE challenge in the payload. The format for the request is illustrated in FIG. 4B and discussed hereinbelow. The EAP-Request/CAVE-Challenge message contains a challenge, which is a random number generated by the authenticator 204.
The MS 202 then computes an authentication response by applying: 1) secret data; 2) the IMSI of MS 202; and 3) the challenge received, as input to the CAVE algorithm. The result is then provided as an “EAP-Response/CAVE-Challenge” message or response to the authenticator 204. The MS 202 sends the EAP-Response/CAVE-Challenge message to the authenticator 204, wherein the message contains the authentication response. The message does not necessarily contain the MS 202 identify (e.g., IMSI or alias name) and/or the challenge, because the message will use the same message identifier as the EAP-Request/CAVE-Challenge message sent by the authenticator 204 originally. Via the message identifier, the authenticator 204 may associate the MS 202 authentication response with the MS 202 identity and the challenge.
The authenticator 204 then verifies the MS 202 authentication response by comparing it with the expected response. The authenticator 204 may or may not know the MS 202 shared secret. If the authenticator 204 knows, or has knowledge of, the shared secret, the authenticator 204 computes an expected response by using the MS's shared secret, MS's IMSI, and the challenge as input to the CAVE algorithm. If the authenticator 204 does not have the secret, it obtains the expected response from the entity that has the MS 202 shared secret.
If the MS 202 authentication response is the same as the expected response, the MS 202 passes the authentication, and the authenticator 204 sends the “EAP-Success” message, so indicating, to the MS 202. If the MS 202 fails the authentication, the authenticator 204 sends an “EAP-Failure” message (not shown), indicating the authenticator 204 was unable to authenticate the MS 202 for the desired access, to the MS 202.
FIG. 4B illustrates the extension of the EAP for application of CAVE authentication procedures. As illustrated, the TYPE field 308 is extended to TYPE filed 312 which includes a CAVE option. The associated PAYLOAD field 314 is then adapted to include a CAVE message, e.g., CAVE challenge or CAVE response. In this way, the EAP may be used with CAVE authentication procedures. Specifically, the EAP will be the transport mechanism for the negotiations involved in the CAVE authentication. CAVE specifies the messages and the order of messages required for authentication. CAVE further specifies the authentication procedures performed at the MS 202 and the authenticator 204, as well as the information and variables needed for such authentication. The EAP specifies how the information and variables, messages, etc. to implement CAVE authentication are communicated between the MS 202 and the authenticator 204. Once the CAVE option is specified in the EAP message, the content of the CAVE message(s) is invisible to the EAP procedures.
FIGS. 5A and 5B illustrate various scenarios for implementation of CAVE with EAP. In FIG. 5A, the EAP request message from the authenticator 204 is made as a CAVE challenge. In other words, the TYPE field 312 identifies the request as a CAVE message, and the PAYLOAD field 314 contains the CAVE message, which in this case is a CAVE challenge. The MS 202 receives the CAVE challenge via the EAP request message, processes the received information contained in the PAYLOAD field 314 according to the CAVE procedures, and provides the result as a CAVE response back to the authenticator 204 via an EAP response message.
In FIG. 5B, the EAP request message from the authenticator 204 is made according to another authentication procedure referred to as the “MD5-Challenge,” which is also known as the Challenge Handshake Authentication Protocol (CHAP). The MS 202 receives the EAP request message but does not support the MD5-Challenge procedures and therefore replies with a Negative Acknowledge message as an EAP response message. Note that the messages sent between the authenticator 204 and the MS 202 are EAP messages. The authenticator 204 receives the NAK via the EAP response message and attempts to authenticate using another type of algorithm. The authenticator 204 may try any number of algorithm types as supported by the EAP format. In this case, the authenticator 204 sends a CAVE challenge in an EAP request message. The MS 202 receives the information, calculates a response, and responds with a CAVE response in an EAP response message. In this way, the authenticator 204 is able to determine the capability of the MS 202 and respond accordingly.
FIG. 6 is a flow diagram of authentication procedures according to one embodiment at the authenticator 204. The process 400 begins when the authenticator 204 receives a request for a given service at step 402. The request for service may for data services, voice services, or a combination thereof. The authenticator 204 then determines if the communication is voice or data at decision diamond 404. Note that a combination type service, such as Voice over IP (VoIP) is typically treated as a data communication. For data services, processing continues to step 406 to send an EAP request for identification of the MS 202. The authenticator 204 receives a response from the MS 202 at step 408. In response to the MS 202 identification, the authenticator 204 sends a CAVE challenge via an EAP request message at step 410.
The authenticator 204 then determines the status of the authentication procedure at decision diamond 416. If the authentication of MS 202 passed, the authenticator 204 authorizes the service at step 418. If the authentication of MS 202 fails, then the authenticator 204 notifies the MS 202 of a failure to authenticate at step 420.
For voice communications, from decision diamond 404 the authenticator 204 sends a CAVE challenge as a signaling message at step 412. The authenticator 204 receives a CAVE response at step 414. The processing then continues to decision diamond 416 to determine the status of the authentication.
FIG. 7 is a flow diagram of an authentication procedure at the MS 202. The MS 202 sends a request for data services at step 502. In response thereto, the MS 202 receives a request for identification in an EAP request message at 504. The MS 202 then sends identification information in an EAP response message at step 506. A challenge is received via an EAP request message at step 508. At decision diamond 510, the MS 202 determines the format of the challenge. If the format is according to the CAVE algorithm, then processing continues to step 512; else processing continues to step 518 to send a NAK message via an EAP response. From step 518 processing returns to step 508 to await another challenge. If the challenge was a CAVE challenge, then processing at step 512 computes a response as described hereinabove and consistent with CAVE procedures. The MS 202 sends the response as an EAP response message at step 514. The MS then receives confirmation of the authentication at step 516 and the authentication procedure is complete.
A wireless device, such as MS 202, is illustrated in FIG. 8. The device 600 includes receive circuitry 602 and transmit circuitry 604 for receiving transmissions and sending transmissions, respectively. The receive circuitry 602 and the transmit circuitry 604 are both coupled to a communication bus 612. The device 600 also includes a Central Processing Unit (CPU) 606 for controlling operations within the device 600. The CPU 606 is responsive to computer-readable instructions stored in memory storage devices within the device 600. Two such storage devices are illustrated as storing the CAVE procedure 608 and the EAP procedure 610. Note that alternate embodiments may implement the procedure in hardware, software, firmware, or a combination thereof. The CPU 606 is then responsive to authentication processing instructions from the CAVE procedure 608. The CPU 606 places the CAVE procedure 608 messages into an EAP format in response to EAP procedure 610. The CPU 606 further processes received EAP messages to extract the CAVE messages therefrom.
Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (4)

1. A method for allowing a device capable of both a voice communication and a packet data communication to use a single voice communication authentication format for authentication of either voice communications or packet data communications, the method comprising:
receiving a request from die device for a given service;
determining if the given service is for a voice communication or a packet data communication;
if the given service is a voice communication, then:
sending a challenge in the voice communication authentication format;
receiving a response in the voice communication authentication format; and
performing authentication of the device using the voice communication authentication format;
if the given service is a packet data communication, then:
sending a challenge in a packet data communication authentication format;
receiving a response in die packet data communication authentication format;
embedding a voice communication challenge into a packet data communication request;
sending the embedded voice communication challenge; and
performing authentication of the device using the voice communication authentication format.
2. Apparatus for allowing a device capable of both a voice communication and a packet data communication to use a single voice communication authentication format for authentication of either voice communications or packet data communications, the apparatus comprising:
means for receiving a request from the device for a given service;
means determining if the given service is for a voice communication or a packet data communication;
means for sending a challenge in the voice communication authentication format, receiving a response in the voice communication authentication format, and performing authentication of the device using the voice communication authentication format, if the given service is a voice communication; and
means for sending a challenge in a packet data communication authentication format, receiving a response in the packet data communication authentication format, embedding a voice communication challenge into a packet data communication request, sending the embedded voice communication challenge and performing authentication of the device using the voice communication authentication format, if the given service is a packet data communication.
3. A method for allowing a device capable of both a voice communication and a packet data communication to use a single voice communication authentication format for authentication of either voice communications or packer data communications, the method comprising:
sending a request for packet data services to an authenticator;
receiving a request for identification in a packet data format;
sending identification to the authenticator in the packet data format;
receiving a challenge;
determining whether the received challenge is formatted according to a voice communication authentication format;
if the received challenge is not formatted according to the voice communication authentication format, then sending a negative acknowledgment in the packet data format; and
if the received challenge is formatted according to the voice communication authentication format, then:
computing a response consistent with the voice communication authentication format; and
sending the response in a packet data format.
4. Apparatus for allowing a device capable of both a voice communication and a packet data communication to use a single voice communication authentication format for authentication of either voice communications or packet data communications, the apparatus comprising:
means for sending a request for packet data services to an authenticator;
means for receiving a request for identification in a packet data format;
means for sending identification to the authenticator in the packet data format;
means for receiving a challenge;
means for determining whether the received challenge is formatted according to a voice communication authentication format;
means for sending a negative acknowledgment in the packet data format if the received challenge is not formatted according to the voice communication authentication format; and
means for computing a response consistent with the voice communication authentication format, and sending the response in a packet data format if the received challenge is formatted according to the voice communication authentication format.
US10/987,509 2002-06-20 2004-11-12 Authentication in a communication system Expired - Fee Related US7197763B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/987,509 US7197763B2 (en) 2002-06-20 2004-11-12 Authentication in a communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/177,088 US20030236980A1 (en) 2002-06-20 2002-06-20 Authentication in a communication system
US10/987,509 US7197763B2 (en) 2002-06-20 2004-11-12 Authentication in a communication system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/177,088 Continuation US20030236980A1 (en) 2002-06-20 2002-06-20 Authentication in a communication system

Publications (2)

Publication Number Publication Date
US20050090232A1 US20050090232A1 (en) 2005-04-28
US7197763B2 true US7197763B2 (en) 2007-03-27

Family

ID=29734291

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/177,088 Abandoned US20030236980A1 (en) 2002-06-20 2002-06-20 Authentication in a communication system
US10/987,509 Expired - Fee Related US7197763B2 (en) 2002-06-20 2004-11-12 Authentication in a communication system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/177,088 Abandoned US20030236980A1 (en) 2002-06-20 2002-06-20 Authentication in a communication system

Country Status (12)

Country Link
US (2) US20030236980A1 (en)
EP (1) EP1535183A4 (en)
JP (2) JP2005530457A (en)
KR (1) KR100961797B1 (en)
CN (1) CN100390773C (en)
AU (1) AU2003247574A1 (en)
BR (1) BR0311951A (en)
CA (1) CA2489839A1 (en)
HK (1) HK1085027A1 (en)
RU (1) RU2326429C2 (en)
TW (1) TWI315625B (en)
WO (1) WO2004001985A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030236982A1 (en) * 2002-06-20 2003-12-25 Hsu Raymond T. Inter-working function for a communication system
US20070206515A1 (en) * 2006-03-06 2007-09-06 Andreasen Flemming S System and method for generating a unified accounting record for a communication session
US20070217610A1 (en) * 2006-03-06 2007-09-20 Parviz Yegani System and Method for Access Authentication in a Mobile Wireless Network

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7107041B1 (en) * 1999-11-22 2006-09-12 Telefonaktiebolaget Lm Ericsson (Publ) Method for monitoring authentication performance in wireless communication networks
US9020114B2 (en) * 2002-04-29 2015-04-28 Securus Technologies, Inc. Systems and methods for detecting a call anomaly using biometric identification
US7181196B2 (en) * 2003-05-15 2007-02-20 Lucent Technologies Inc. Performing authentication in a communications system
CN1549482B (en) * 2003-05-16 2010-04-07 华为技术有限公司 Method for realizing high rate group data service identification
CN1601958B (en) * 2003-09-26 2010-05-12 北京三星通信技术研究有限公司 HRPD network access authentication method based on CAVE algorithm
CN1661960B (en) 2004-02-27 2010-04-07 北京三星通信技术研究有限公司 Authentication method of separation between device and card by using CAVE as access authentication algorithm and equipment
US7734929B2 (en) 2004-04-30 2010-06-08 Hewlett-Packard Development Company, L.P. Authorization method
KR20050122343A (en) * 2004-06-24 2005-12-29 엑서스테크놀러지 주식회사 Network integrated management system
US8286223B2 (en) 2005-07-08 2012-10-09 Microsoft Corporation Extensible access control architecture
US7917949B2 (en) * 2005-12-21 2011-03-29 Sandisk Corporation Voice controlled portable memory storage device
US20070143117A1 (en) * 2005-12-21 2007-06-21 Conley Kevin M Voice controlled portable memory storage device
US8161289B2 (en) * 2005-12-21 2012-04-17 SanDisk Technologies, Inc. Voice controlled portable memory storage device
KR100880979B1 (en) * 2006-02-27 2009-02-03 삼성전자주식회사 Authentication method and apparatus in a mobile broadcast system
JP5580318B2 (en) * 2008-10-14 2014-08-27 コーニンクレッカ フィリップス エヌ ヴェ Method and apparatus for kana generation and authentication
SE535546C2 (en) * 2009-07-14 2012-09-18 Ericsson Telefon Ab L M Method and apparatus for verifying a telephone number
US8904167B2 (en) * 2010-01-22 2014-12-02 Qualcomm Incorporated Method and apparatus for securing wireless relay nodes
US8661515B2 (en) * 2010-05-10 2014-02-25 Intel Corporation Audible authentication for wireless network enrollment
CN102185868B (en) * 2011-05-20 2014-10-22 杭州华三通信技术有限公司 Authentication method, system and equipment based on extensible authentication protocol (EAP)
KR101306306B1 (en) 2012-05-14 2013-09-09 에스케이텔레콤 주식회사 Network apparatus and terminal device, and control method thereof
KR101972955B1 (en) * 2012-07-03 2019-04-26 삼성전자 주식회사 Method and apparatus for connecting service between user devices using voice
US9680646B2 (en) * 2015-02-05 2017-06-13 Apple Inc. Relay service for communication between controllers and accessories
CN104899482B (en) * 2015-03-31 2018-09-28 北京京东尚科信息技术有限公司 The method and apparatus of limitation batch request service
US9967732B2 (en) 2016-08-15 2018-05-08 At&T Intellectual Property I, L.P. Method and apparatus for managing mobile subscriber identification information according to registration errors
US9838991B1 (en) 2016-08-15 2017-12-05 At&T Intellectual Property I, L.P. Method and apparatus for managing mobile subscriber identification information according to registration requests
US9814010B1 (en) 2016-09-14 2017-11-07 At&T Intellectual Property I, L.P. Method and apparatus for utilizing mobile subscriber identification information with multiple devices based on registration requests
US9843922B1 (en) 2016-09-14 2017-12-12 At&T Intellectual Property I, L.P. Method and apparatus for utilizing mobile subscriber identification information with multiple devices based on registration errors
US9794905B1 (en) 2016-09-14 2017-10-17 At&T Mobility Ii Llc Method and apparatus for assigning mobile subscriber identification information to multiple devices according to location
US9924347B1 (en) 2016-09-14 2018-03-20 At&T Intellectual Property I, L.P. Method and apparatus for reassigning mobile subscriber identification information
US10015764B2 (en) 2016-09-14 2018-07-03 At&T Intellectual Property I, L.P. Method and apparatus for assigning mobile subscriber identification information to multiple devices
US9906943B1 (en) 2016-09-29 2018-02-27 At&T Intellectual Property I, L.P. Method and apparatus for provisioning mobile subscriber identification information to multiple devices and provisioning network elements
US9918220B1 (en) 2016-10-17 2018-03-13 At&T Intellectual Property I, L.P. Method and apparatus for managing and reusing mobile subscriber identification information to multiple devices
US10070303B2 (en) 2016-11-11 2018-09-04 At&T Intellectual Property I, L.P. Method and apparatus for provisioning of multiple devices with mobile subscriber identification information
US10341842B2 (en) 2016-12-01 2019-07-02 At&T Intellectual Property I, L.P. Method and apparatus for using temporary mobile subscriber identification information in a device to provide services for a limited time period
US10136305B2 (en) * 2016-12-01 2018-11-20 At&T Intellectual Property I, L.P. Method and apparatus for using mobile subscriber identification information for multiple device profiles for a device
US10070407B2 (en) 2016-12-01 2018-09-04 At&T Intellectual Property I, L.P. Method and apparatus for using active and inactive mobile subscriber identification information in a device to provide services for a limited time period
US10231204B2 (en) 2016-12-05 2019-03-12 At&T Intellectual Property I, L.P. Methods, systems, and devices for registering a communication device utilizing a virtual network

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6085247A (en) * 1998-06-08 2000-07-04 Microsoft Corporation Server operating system for supporting multiple client-server sessions and dynamic reconnection of users to previous sessions using different computers
US6144848A (en) * 1995-06-07 2000-11-07 Weiss Jensen Ellis & Howard Handheld remote computer control and methods for secured interactive real-time telecommunications
US20020006137A1 (en) * 2000-05-08 2002-01-17 Rabenko Theodore F. System and method for supporting multiple voice channels
US6349337B1 (en) * 1997-11-14 2002-02-19 Microsoft Corporation Maintaining a first session on a first computing device and subsequently connecting to the first session via different computing devices and adapting the first session to conform to the different computing devices system configurations
US20020141585A1 (en) * 2001-01-24 2002-10-03 Broadcom Corporation Method for processing multiple security policies applied to a data packet structure
US20020184527A1 (en) * 2001-06-01 2002-12-05 Chun Jon Andre Intelligent secure data manipulation apparatus and method
US6502144B1 (en) * 1998-01-19 2002-12-31 Canon Kabushiki Kaisha Data processing apparatus with communication feature, and communication method in a data processing apparatus
US20030051041A1 (en) * 2001-08-07 2003-03-13 Tatara Systems, Inc. Method and apparatus for integrating billing and authentication functions in local area and wide area wireless data networks
US6769000B1 (en) * 1999-09-08 2004-07-27 Nortel Networks Limited Unified directory services architecture for an IP mobility architecture framework
US20050220086A1 (en) * 1998-07-21 2005-10-06 Dowling Eric M Method and apparatus for co-socket telephony
US6996631B1 (en) * 2000-08-17 2006-02-07 International Business Machines Corporation System having a single IP address associated with communication protocol stacks in a cluster of processing systems
US7023868B2 (en) * 1999-04-13 2006-04-04 Broadcom Corporation Voice gateway with downstream voice synchronization
US7116646B1 (en) * 2000-03-07 2006-10-03 Telefonakitebolaget Lm Ericsson (Publ) CDMA internet protocol mobile telecommunications network architecture and methodology

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10149237A (en) * 1996-11-20 1998-06-02 Kyushu Syst Joho Gijutsu Kenkyusho Semiconductor circuit
JPH10285630A (en) * 1997-03-31 1998-10-23 Mitsubishi Electric Corp Wide area roaming authentication device and wide area roaming authentication method for portable radio telephony equipment
US6334185B1 (en) * 1998-09-08 2001-12-25 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for centralized encryption key calculation
EP1075123A1 (en) * 1999-08-06 2001-02-07 Lucent Technologies Inc. Dynamic home agent system for wireless communication systems
CN1158882C (en) * 2000-03-01 2004-07-21 中国联合通信有限公司 Method for realizing telephone set/card separation on CDMA mobile communication net
WO2002009458A2 (en) * 2000-07-24 2002-01-31 Bluesocket, Inc. Method and system for enabling seamless roaming in a wireless network
JP2002077441A (en) * 2000-09-01 2002-03-15 Yozan Inc Communication terminal
US20030095663A1 (en) * 2001-11-21 2003-05-22 Nelson David B. System and method to provide enhanced security in a wireless local area network system
US7593717B2 (en) * 2003-09-12 2009-09-22 Alcatel-Lucent Usa Inc. Authenticating access to a wireless local area network based on security value(s) associated with a cellular system
CN1601958B (en) * 2003-09-26 2010-05-12 北京三星通信技术研究有限公司 HRPD network access authentication method based on CAVE algorithm

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6144848A (en) * 1995-06-07 2000-11-07 Weiss Jensen Ellis & Howard Handheld remote computer control and methods for secured interactive real-time telecommunications
US6349337B1 (en) * 1997-11-14 2002-02-19 Microsoft Corporation Maintaining a first session on a first computing device and subsequently connecting to the first session via different computing devices and adapting the first session to conform to the different computing devices system configurations
US6502144B1 (en) * 1998-01-19 2002-12-31 Canon Kabushiki Kaisha Data processing apparatus with communication feature, and communication method in a data processing apparatus
US6085247A (en) * 1998-06-08 2000-07-04 Microsoft Corporation Server operating system for supporting multiple client-server sessions and dynamic reconnection of users to previous sessions using different computers
US20050220086A1 (en) * 1998-07-21 2005-10-06 Dowling Eric M Method and apparatus for co-socket telephony
US7023868B2 (en) * 1999-04-13 2006-04-04 Broadcom Corporation Voice gateway with downstream voice synchronization
US6769000B1 (en) * 1999-09-08 2004-07-27 Nortel Networks Limited Unified directory services architecture for an IP mobility architecture framework
US7116646B1 (en) * 2000-03-07 2006-10-03 Telefonakitebolaget Lm Ericsson (Publ) CDMA internet protocol mobile telecommunications network architecture and methodology
US20020006137A1 (en) * 2000-05-08 2002-01-17 Rabenko Theodore F. System and method for supporting multiple voice channels
US6996631B1 (en) * 2000-08-17 2006-02-07 International Business Machines Corporation System having a single IP address associated with communication protocol stacks in a cluster of processing systems
US20020141585A1 (en) * 2001-01-24 2002-10-03 Broadcom Corporation Method for processing multiple security policies applied to a data packet structure
US20020184527A1 (en) * 2001-06-01 2002-12-05 Chun Jon Andre Intelligent secure data manipulation apparatus and method
US20030051041A1 (en) * 2001-08-07 2003-03-13 Tatara Systems, Inc. Method and apparatus for integrating billing and authentication functions in local area and wide area wireless data networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Juha Ala-Laurila et seq., "wireless Lan access network architecture for mobile operators", Nov. 2001, IEEE Communication Magazine, pp. 82-89. *

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030236982A1 (en) * 2002-06-20 2003-12-25 Hsu Raymond T. Inter-working function for a communication system
US8630414B2 (en) 2002-06-20 2014-01-14 Qualcomm Incorporated Inter-working function for a communication system
US7940722B1 (en) 2006-03-06 2011-05-10 Cisco Technology, Inc. System and method for determining a network for processing applications for a communication session
US8719895B1 (en) 2006-03-06 2014-05-06 Cisco Technology, Inc. Determining a policy output for a communication session
US20070206617A1 (en) * 2006-03-06 2007-09-06 Andreasen Flemming S Network-triggered quality of service (QoS) reservation
US20070206557A1 (en) * 2006-03-06 2007-09-06 Iyer Jayaraman R Access terminal for communicating packets using a home anchored bearer path or a visited anchored bearer path
US20070220588A1 (en) * 2006-03-06 2007-09-20 Biswaranjan Panda Application-aware policy enforcement
US20070217610A1 (en) * 2006-03-06 2007-09-20 Parviz Yegani System and Method for Access Authentication in a Mobile Wireless Network
US20070220251A1 (en) * 2006-03-06 2007-09-20 Rosenberg Jonathan D Establishing facets of a policy for a communication session
US7715562B2 (en) 2006-03-06 2010-05-11 Cisco Technology, Inc. System and method for access authentication in a mobile wireless network
US7805127B2 (en) 2006-03-06 2010-09-28 Cisco Technology, Inc. System and method for generating a unified accounting record for a communication session
US7912035B1 (en) 2006-03-06 2011-03-22 Cisco Technology, Inc. Communicating packets using a home anchored bearer path or a visited anchored bearer path
US7929966B2 (en) 2006-03-06 2011-04-19 Cisco Technology, Inc. Access terminal for communicating packets using a home anchored bearer path or a visited anchored bearer path
US7936722B2 (en) 2006-03-06 2011-05-03 Cisco Technology, Inc. System and method for handover of an access terminal in a communication network
US20070207818A1 (en) * 2006-03-06 2007-09-06 Rosenberg Jonathan D System and method for exchanging policy information in a roaming communications environment
US20070206539A1 (en) * 2006-03-06 2007-09-06 Parviz Yegani System and method for handover of an access terminal in a communication network
US8050391B1 (en) 2006-03-06 2011-11-01 Cisco Technology, Inc. System and method for capturing accounting data for a communication session
US7966645B2 (en) 2006-03-06 2011-06-21 Cisco Technology, Inc. Application-aware policy enforcement
US7991385B1 (en) 2006-03-06 2011-08-02 Cisco Technology, Inc. System and method for network charging using policy peering
US7995990B1 (en) 2006-03-06 2011-08-09 Cisco Technology, Inc. System and method for consolidating accounting data for a communication session
US8041022B1 (en) 2006-03-06 2011-10-18 Cisco Technology, Inc. Policy-based control of content intercept
US8040862B1 (en) 2006-03-06 2011-10-18 Cisco Technology, Inc. System and method for providing emergency services in a visited communications environment
US8045959B1 (en) 2006-03-06 2011-10-25 Cisco Technology, Inc. Assigning a serving-CSCF during access authentication
US7962123B1 (en) 2006-03-06 2011-06-14 Cisco Technology, Inc. Authentication of access terminals in a cellular communication network
US8160579B1 (en) 2006-03-06 2012-04-17 Cisco Technology, Inc. Performing deep packet inspection for a communication session
US8295242B2 (en) 2006-03-06 2012-10-23 Cisco Technology, Inc. System and method for exchanging policy information in a roaming communications environment
US8438613B2 (en) 2006-03-06 2013-05-07 Cisco Technology, Inc. Establishing facets of a policy for a communication session
US20070206515A1 (en) * 2006-03-06 2007-09-06 Andreasen Flemming S System and method for generating a unified accounting record for a communication session
US7944875B1 (en) 2006-03-06 2011-05-17 Cisco Technology, Inc. Enforcement of user level policies from visited networks in a mobile IP environment

Also Published As

Publication number Publication date
KR20050010959A (en) 2005-01-28
RU2005101215A (en) 2005-08-27
HK1085027A1 (en) 2006-08-11
US20050090232A1 (en) 2005-04-28
WO2004001985A2 (en) 2003-12-31
EP1535183A4 (en) 2010-08-11
CN100390773C (en) 2008-05-28
KR100961797B1 (en) 2010-06-08
JP2005530457A (en) 2005-10-06
EP1535183A2 (en) 2005-06-01
WO2004001985A3 (en) 2004-03-11
AU2003247574A1 (en) 2004-01-06
US20030236980A1 (en) 2003-12-25
CN1726483A (en) 2006-01-25
RU2326429C2 (en) 2008-06-10
TWI315625B (en) 2009-10-01
TW200421807A (en) 2004-10-16
JP2011141877A (en) 2011-07-21
BR0311951A (en) 2005-05-10
JP5199405B2 (en) 2013-05-15
CA2489839A1 (en) 2003-12-31

Similar Documents

Publication Publication Date Title
US7197763B2 (en) Authentication in a communication system
US7190793B2 (en) Key generation in a communication system
EP1478204B1 (en) Method and apparatus for performing authentication in a communications system
US8176327B2 (en) Authentication protocol
KR101068424B1 (en) Inter-working function for a communication system
US8094821B2 (en) Key generation in a communication system
KR101068426B1 (en) Inter-working function for a communication system

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 8

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20190327