AU2001292955A1 - Internet protocol telephony security architecture - Google Patents

Internet protocol telephony security architecture

Info

Publication number
AU2001292955A1
AU2001292955A1 AU2001292955A AU9295501A AU2001292955A1 AU 2001292955 A1 AU2001292955 A1 AU 2001292955A1 AU 2001292955 A AU2001292955 A AU 2001292955A AU 9295501 A AU9295501 A AU 9295501A AU 2001292955 A1 AU2001292955 A1 AU 2001292955A1
Authority
AU
Australia
Prior art keywords
server
nonce
client
message
key management
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.)
Abandoned
Application number
AU2001292955A
Inventor
Sasha Medvinsky
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.)
Arris Technology Inc
Original Assignee
Arris Technology Inc
General Instrument Corp
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
Priority claimed from US09/668,426 external-priority patent/US6892308B1/en
Application filed by Arris Technology Inc, General Instrument Corp filed Critical Arris Technology Inc
Publication of AU2001292955A1 publication Critical patent/AU2001292955A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/22Arrangements for preventing the taking of data from a data transmission channel without authorisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/38Graded-service arrangements, i.e. some subscribers prevented from establishing certain connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0078Security; Fraud detection; Fraud prevention
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431Key distribution or pre-distribution; Key agreement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12Detection or prevention of fraud
    • H04W12/121Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122Counter-measures against attacks; Protection against rogue devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/38Graded-service arrangements, i.e. some subscribers prevented from establishing certain connections
    • H04M3/387Graded-service arrangements, i.e. some subscribers prevented from establishing certain connections using subscriber identification cards
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/0093Arrangements for interconnection between switching centres signalling arrangements in networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Alarm Systems (AREA)

Abstract

A system is provided in which a client/server/ network can implement a key management session when the server initiates the key management session utilizing a nonce. The nonce allows a wakeup or trigger message to be conveyed to the client such that a service attack on the server can be avoided when a false nonce is received by the server with an AP request message. Thus the server can disregard AP request messages that are not accompanied by a nonce stored by the server. The method can be implemented through circuitry, electrical signals and code to accomplish the acts described in the method.

Description

INTERNET PROTOCOL TELEPHONY SECURITY ARCHITECTURE
This application claims priority from co-pending PCT Application No. PCT/US00/09318 filed on April 1, 2000 entitled, "Built-in Manufacturer's Certificates for a Cable Telephony Adapter to Provide Device and Service Certification," which claims priority from U.S. Application No. 60/128,772 entitled, "Internet Protocol Telephony Security Architecture" filed on April 9, 1999, as well as PCT Application No. PCT USOO/02174 filed on January 28, 2000 entitled "Key Management for Telephone Calls to Protect Signaling and Call Packets Between CTA' s," all of which are hereby incorporated by reference for all that they disclose and for all purposes.
BACKGROUND This invention relates generally to network security, and more particularly, to a system for providing key management between a server and a client, e.g., in a telephony or an IP telephony network.
In networks that are based on a client server configuration, there is a need to establish a secure channel between the server and the clients. In addition, in networks that utilize a third party to certify a trust relationship, there is a need to provide an efficient mechanism that allows a key management message to be initiated by the server. In such networks that utilize a trusted third party for the server and client, the client can typically request an encrypted authentication token from the trusted third party that can be used to initiate key management with the specified server; however, the server will typically initiate the key management session directly with the client. It is less preferable for the server to obtain from the trusted third party encrypted authentication tokens for each of the clients. Such an approach would add overhead to a server, requiring it to maintain cryptographic state for each of the clients. If such a server were to fail, a backup server would be required to undergo a recovery procedure in which it has to obtain new authentication tokens for each of the clients. The clients need to be initialized during their provisioning phase to allow them to successfully authenticate to a trusted third party and obtain the encrypted authentication tokens. One proposed method for client initialization is disclosed in PCT Application No. PCT/US00/09318 entitled "BUILT-IN MANUFACTURER'S CERTIFICATES FOR A CABLE TELEPHONY ADAPTER TO PROVIDE DEVICE AND SERVICE CERTIFICATION." Nevertheless, a need exists to provide an efficient mechanism through which the server can initiate the key management session with the client, as opposed to a system in which only the client can initiate such a session. One such client/server network is the client/server network that exists in IP telephony. In IP telephony systems, a cable telephony adapter (CTA) device can be used to allow a user to send and receive information in secure transactions over an IP telephony network. In typical operation, a series of signaling messages are exchanged that register the CTA device with the IP telephony network before a secure channel with another user can be established. Therefore, the CTA device needs to be authenticated by the IP telephony system. Otherwise, the process would be open to denial of service attacks — since some provisioning exchanges can be forged. In addition, it is desirable for the service provider to identify the CTA device — to make sure that only authorized devices are allowed in its IP Telephony network.
SUMMARY OF THE INVENTION One embodiment of the invention comprises a system for providing key management in a client/server network. This embodiment of the invention utilizes a method to provide key management by providing a server; providing a client configured to be coupled to the server; providing a trusted third party configured to be coupled to the client; and allowing the server to initiate the key management session with the client.
One embodiment is operable as a method to generate a trigger message at the server; generate a nonce at the server; and, convey the trigger message and the nonce to the client. At the client, the client receives the trigger message and the nonce and responds by conveying a response message with a return nonce. The server can then determine that the response message is valid by comparing the values of the returned_nonce and the nonce that was generated by the server.
In addition, one embodiment can be implemented in code and by circuitry operable to produce the acts of the method. A further understanding of the nature of the inventions disclosed herein
" will be realized by reference to the remaining portions of the specification and the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows a flow chart demonstrating an overview of one embodiment of the invention.
FIGS. 2 A and 2B show a more detailed flow chart demonstrating a key management session between a server and a client.
FIG. 3 shows steps of a key management session after the key management session is initiated.
FIG. 4 shows a general block diagram of a client/server/trusted third party network. FIG. 5 shows a block diagram of an IP telephony network in which a cable telephony adapter, a signaling controller, and a key distribution center are coupled with one another.
FIG. 6 shows the implementation of the data structures for establishing a key management session as implemented by one embodiment of the invention.
DESCRIPTION OF THE SPECIFIC EMBODIMENTS FIG. 1 shows a flow chart demonstrating an overview of one embodiment of the invention. In flow chart 100, a server is provided 104 and a client coupled to the server is also provided 108. A trusted third party for the server and the client is provided 112 and the server is allowed to initiate a key management session with the client by utilizing a nonce 116.
It should be understood that a server is a shared computer on a network, such as a signaling controller used in an IP telephony network. Furthermore, it should be understood that a client is a computer or device served by another network computing device, such as a cable telephony adapter (client) being served by a signaling controller (server) via an IP telephony system. In addition, it should be understood that a trusted third party for the server and the client is a device or computer utilized by at least two parties that facilitates cryptographic processes such as certifying the identity of one of the two parties to the other. Finally, it should be understood that a nonce is a number generated that is utilized only once. The use of a nonce helps to prevent an attacker from implementing a replay attack. Such a nonce can be generated randomly.
The method of FIG. 1 can be better understood by reference to FIG. 2A and FIG. 2B. In the method designated 200 in FIG. 2A and FIG. 2B, a server such as a signaling controller in an IP telephony system is provided 204. In addition, a client such as a cable telephony adapter in an IP telephony system is also provided 208. A trusted third party for the client and server, such as a key distribution center in an IP telephony system, is provided 212, as well. The server, client, and trusted third party are coupled to one another. Typically, the client initiates key management sessions with the server. However, there will be times when the server will need to initiate a key management session with the client. Rather than authenticating the trigger message (e.g. with a digital signature and certificate), the invention can utilize a nonce in the authentication of the subsequent AP Request message from the client. This embodiment of the invention does not prevent an adversary (impersonating a legitimate server) from sending an illicit trigger message to the client and fooling it into responding with an AP Request. Instead it provides that such an AP Request will be rejected by the legitimate server. This mechanism is designed to reduce the server's overhead of initiating key management exchanges with its clients, while still maintaining sufficient security. Thus, in 216 a trigger message is generated at the server to initiate a key management session. Then, a nonce is generated at the server 220 and the nonce and trigger message are coupled together and conveyed to the client 224. The client receives the trigger message and the nonce 228. Then the client designates the nonce as a returned_nonce 232. In this way, the client can return the received nonce to the server for verification that the message is - from the client. In 236, a second nonce is generated at the client. The second nonce is for use by the server and client as part of the key management session being initiated. The client generates a response message to the trigger message that was received from the server 240. Then the response message, the returnedjtionce, and the second nonce are conveyed to the server 244:
At the server, the value of the returned_nonce is compared to the value of the nonce which was generated at the server. If the values of the returnedjnonce and the nonce stored at the server are equivalent, the key management session can proceed. However, if the value of the returned_nonce does not equal the value of the nonce stored at the server then a determination is made that the returned_nonce is actually a false nonce 252. In such a case there is a possibility that the signal has been corrupted; or, there is a possibility that an attacker is trying to initiate a service attack. In a service attack, the attacker tries to fraudulently initiate a rekeying session in order to cause the server to utilize processor cycles which prevent the processor from utilizing those cycles for other operations. Thus the server would become less effective under such an attack than it would be under normal conditions. By repeating such an attack, an attacker can prevent the server from operating efficiently and thus can compromise the operation of the client server network, such as an IP telephony network. If the returnedjtionce is determined to be not equivalent to the value of the nonce stored at the server, the response message sent with the returned_nonce is disregarded as being unauthenticated 256. However, if the returnedjnonce does equal the value of the nonce stored at the server, then the key management session continues 260.
FIG. 3 shows additional steps in a typical key management session as highlighted by block 260 in FIG. 2B. In FIG. 3, method 300 shows that an application (AP) REPLY is generated 364 by the server. The AP REPLY is conveyed to the client with the second nonce that was generated by the client 368. The AP Request is an abbreviation for Application Request and AP Reply stands for Application Reply. For example, these two messages can be specified by the Kerberos Key Management standard (see IETF RFC 1510). As a further example, in the context of Kerberos, the second notice can be the client's time expressed in microseconds. When the AP REPLY and second nonce are received at the client, the client transmits a security association (S A) recovered message to the server 372. This completes the applicable Kerberos key management session.
FIG. 4 shows a block diagram of a client/server/trusted third party network. A client 401 is coupled with a server 402. In addition, the client is coupled with a trusted third party 404. The trusted third party is also coupled with the server 402. FIG. 4 thus demonstrates the network within which one embodiment of the invention can be implemented.
In FIG. 5 an IP telephony network implementing one embodiment of the invention is demonstrated. A client such as a cable telephony, adapter 501 is coupled with a server, such as signaling controller 502. Furthermore, the cable telephony adapter and signaling controller are also coupled to a trusted third party, illustrated as key distribution center 504. Furthermore the signaling controller is coupled with the IP telephony network 508. Such a network as that illustrated in FIG. 5 would be useful for establishing an IP telephony call from a user who is coupled to the cable telephony adapter through the IP telephony network 508 to another user connected to a similar network. Thus the user can be authenticated as the calling party through the cable telephony adapter and signaling controller when the call is placed across the IP telephony network. Further details of such a network are illustrated in the references which were incorporated by reference. FIG. 6 illustrates data structures for implementing a Kerberos key management session initiated by a server in a client/server network. In FIG. 6 a nonce number 1 is coupled with an initiation signal such as a trigger or wakeup message and the combined message is transmitted across an interface 601 to the client. The client stores nonce number 1. It then adds nonce number 2 and an application request in data structure such as that shown in FIG. 6. This set of data is then transmitted across the interface back to the server. The server compares the value of received nonce number 1 with the value of nonce number 1 stored at the server so as to confirm the authenticity of the AP Request. Upon authenticating the AP Request, the server generates an AP Reply and couples it with nonce number 2 which was generated by the client. The combined nonce number 2 and AP Reply are then transmitted across the interface to the client. The client is able to verify the authenticity of the AP Reply by comparing the value of nonce number 2 received from the server with the value of nonce number 2 stored at the client. Upon authenticating the AP Reply, the client generates a Security Association (SA) recovered message and transmits that across the interface to the server. This Kerberos-based key management protocol is thereby implemented in an efficient way and furthermore allows the server to initiate the key management session with the use of only an additional nonce as overhead to the initiation message. Thus the method is highly efficient in that only a nonce need be used in the authentication process of the initiation message. In addition to embodiments where the invention is accomplished by hardware, it is also noted that these embodiments can be accomplished through the use of an article of manufacture comprised of a computer usable medium having a computer readable program code embodied therein, which causes the enablement of the functions and/or fabrication of the hardware disclosed in this specification. For example, this might be accomplished through the use of hardware description language (HDL), register transfer language (RTL), VERILOG, VHDL, or similar programming tools, as one of ordinary skill in the art would understand. The book "A Verilog HDL Primer" by J. Bhasker, Star Galaxy Pr., 1997 provides greater detail on Verilog and HDL and is hereby incorporated by reference for all that it discloses for all purposes. It is therefore envisioned that the functions accomplished by the present invention as described above could be represented in a core which could be utilized in programming code and transformed to hardware as part of the production of integrated circuits. Therefore, it is desired that the embodiments expressed above also be considered protected by this patent in their program code means as well. It is noted that embodiments of the invention can be accomplished by use of an electrical signal, such as a computer data signal embodied in a carrier wave, to convey the pertinent signals to a receiver. Thus, where code is illustrated as stored on a computer medium, it should also be understood to be conveyable as an electrical signal. Similarly, where a data structure is illustrated for a message, it should be understood to also be capable of being embodied in an electrical signal for transmission across a medium, such as the internet.
It is also noted that many of the structures and acts recited herein can be recited as means for performing a function or steps for performing a function, respectively. Therefore, it should be understood that such language is entitled to cover all such structures or acts disclosed within this specification and their equivalents, including the matter incorporated by reference.
It is thought that the apparatuses and methods of the embodiments of the present invention and many of its attendant advantages will be understood from this specification and it will be apparent that various changes may be made in the form, construction and arrangement of the parts thereof without departing from the spirit and scope of the invention or sacrificing all of its material advantages, the form herein before described being merely exemplary embodiments thereof.

Claims (21)

  1. WHAT IS CLAIMED IS: 1. A method of providing key management comprising: providing a server; providing a client configured to be coupled to said server; providing a trusted third party configured to be coupled to said client; allowing said server to initiate a key management session with said client
  2. 2. The method as described in claim 1 wherein said allowing said server to initiate said key management session with said client comprises: generating a trigger message at said server; generating a nonce at said server; conveying said trigger message and said nonce to said client.
  3. 3. The method as described in claim 2 and further comprising: receiving said trigger message and said nonce at said client; generating a response message to said trigger message; conveying said response message and a returned_nonce to said server.
  4. 4. The method as described in claim 3 and further comprising: predetermining an out-of-bounds value for said nonce to prevent an attacker from simulating a client initiated key management session; checking said nonce to determine whether the value of said nonce is said out-of- bounds value.
  5. 5. The method as described in claim 3 and further comprising: confirming the value of said returned_nonce at said server; and conveying a reply message from said client to said server.
  6. 6. The method as described in claim 1 and further comprising: receiving from said client a response message and a false_nonce at said server; determining that said false_nonce is false; disregarding said client response message.
  7. 7. A method of providing key management in a Kerberos based system, said method comprising: providing a server; providing a client configured to be coupled to said server; providing a key distribution center configured to act as a trusted third party for said client and said server; initiating a key management session by said server with said client.
  8. 8. The method as described in claim 7 and further comprising: generating a trigger message at said server; generating a nonce at said server; conveying said trigger message and said nonce to said client.
  9. 9. The method as described in claim 8 and further comprising: receiving said trigger message and said nonce at said client; generating a response message to said trigger message; conveying said response message and a returned_nonce to said server.
  10. 10. The method as described in claim 9 and further comprising: confirming the value of said returned_nonce at said server; and then continuing with said key management session.
  11. 11. The method as described in claim 7 and further comprising: receiving at said server a response message and a false_nonce from said client; determining that said false_nonce does not match said nonce; determining that said server did not initiate said key management session.
  12. 12. A method of initiating a key management session for a cable telephony adapter (CTA. and a Signaling Controller in an IP Telephony network, the method comprising: providing said Signaling Controller; providing said CTA configured to be coupled to said Signaling Controller; providing a key distribution center (KDC; generating a trigger message at said Signaling Controller; generating a nonce at said Signaling Controller; coupling said nonce with said trigger message; transmitting said nonce coupled with said trigger message to said CTA; generating a response message to said trigger message; using the value of said nonce as the value of a returned_nonce; coupling said response message with said returned_nonce; transmitting said returned_nonce and said response message to said Signaling Controller; comparing said returned_nonce to said nonce; transmitting an AP reply in reply to said response message; transmitting an SA recovered message to said Signalling Controller.
  13. 13. A method of conveying a key from a server to a client, comprising: generating a wakeup message at said server; generating a server_nonce at said server; conveying said wakeup message and said nonce to said client; generating an AP request message at said client; conveying a client_nonce and said AP request message to said server; confirming that said client_nonce conveyed with said AP request message matches said serverjnonce generated at said server;
  14. 14. A method of confirming that a message received by a server from a client was triggered by the server: receiving an AP request message from said client; receiving a client_nonce from said client wherein said client_nonce is associated with said AP request; determining whether said client_nonce matches a nonce conveyed from said server.
  15. 15. The method as described in claim 14 and further comprising: determining that said client_nonce does not match said nonce conveyed from said server; and disregarding said AP request.
  16. 16. The method as described in claim 15 and further comprising: awaiting at said client for a reply from said server to said AP request; aborting said AP request session after a predetermined time period if no reply is received from said server.
  17. 17. The method as described in claim 14 and further comprising: deteiτmning that said clientjnonce does match said nonce conveyed from said server; and generating an AP reply at said server to said AP request.
  18. 18. A system for providing key management in a Kerberos based system, said system comprising: a server; a client configured to be coupled to said server; a key distribution center configured to act as a trusted third party for said client and said server; computer code coupled to said server operable to initiate a key management session by said server with said client.
  19. 19. The system as described in claim 18 wherein said computer code operable to initiate a key management session comprises computer code operable to generate a trigger message at said server; and further comprising: computer code coupled to said server operable to generate a nonce at said server; computer code coupled to said server operable to convey said trigger message and said nonce to said client.
  20. 20. The system as described in claim 19 and further comprising: computer code coupled to said client operable to generate a response message to said trigger message; computer code coupled to said client operable to convey said response message and a returnedXionce to said server.
  21. 21. The system as described in claim 20 and further comprising: computer code coupled to said server operable to confirm the value of said returned nonce at said server.
AU2001292955A 2000-09-22 2001-09-21 Internet protocol telephony security architecture Abandoned AU2001292955A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09668426 2000-09-22
US09/668,426 US6892308B1 (en) 1999-04-09 2000-09-22 Internet protocol telephony security architecture
PCT/US2001/029654 WO2002025899A1 (en) 2000-09-22 2001-09-21 Internet protocol telephony security architecture

Publications (1)

Publication Number Publication Date
AU2001292955A1 true AU2001292955A1 (en) 2002-04-02

Family

ID=24682251

Family Applications (1)

Application Number Title Priority Date Filing Date
AU2001292955A Abandoned AU2001292955A1 (en) 2000-09-22 2001-09-21 Internet protocol telephony security architecture

Country Status (9)

Country Link
EP (1) EP1320975B1 (en)
JP (1) JP2004509567A (en)
KR (1) KR20040014400A (en)
CN (1) CN1285202C (en)
AT (1) ATE312464T1 (en)
AU (1) AU2001292955A1 (en)
CA (1) CA2421628A1 (en)
DE (1) DE60115672T2 (en)
WO (1) WO2002025899A1 (en)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6892308B1 (en) * 1999-04-09 2005-05-10 General Instrument Corporation Internet protocol telephony security architecture
CA2365856C (en) * 1999-04-09 2011-11-01 General Instrument Corporation Key management between a cable telephony adapter and associated signaling controller
US7972632B2 (en) 2003-02-28 2011-07-05 Unigen Pharmaceuticals, Inc. Identification of Free-B-Ring flavonoids as potent COX-2 inhibitors
US7263357B2 (en) * 2003-01-14 2007-08-28 Samsung Electronics Co., Ltd. Method for fast roaming in a wireless network
JP4769184B2 (en) 2003-04-04 2011-09-07 ユニジェン・インコーポレーテッド Formulation of cyclooxygenase (COX) and lipoxygenase (LOX) dual inhibitors for mammalian skin care
CN102333100B (en) * 2007-11-08 2013-11-06 华为技术有限公司 Authentication method and terminal
US20090282256A1 (en) * 2008-05-12 2009-11-12 Sony Ericsson Mobile Communications Ab Secure push messages
CN101683506B (en) * 2008-09-24 2012-11-21 马多伟 Traditional Chinese medicine composition for treating hemorrhoids
US9311500B2 (en) * 2013-09-25 2016-04-12 Amazon Technologies, Inc. Data security using request-supplied keys

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590199A (en) * 1993-10-12 1996-12-31 The Mitre Corporation Electronic information network user authentication and authorization system
US5668876A (en) * 1994-06-24 1997-09-16 Telefonaktiebolaget Lm Ericsson User authentication method and apparatus
US5740361A (en) * 1996-06-03 1998-04-14 Compuserve Incorporated System for remote pass-phrase authentication

Also Published As

Publication number Publication date
KR20040014400A (en) 2004-02-14
EP1320975B1 (en) 2005-12-07
EP1320975A1 (en) 2003-06-25
CN1285202C (en) 2006-11-15
ATE312464T1 (en) 2005-12-15
CN1476709A (en) 2004-02-18
JP2004509567A (en) 2004-03-25
DE60115672D1 (en) 2006-01-12
DE60115672T2 (en) 2006-07-20
CA2421628A1 (en) 2002-03-28
WO2002025899A1 (en) 2002-03-28

Similar Documents

Publication Publication Date Title
US6892308B1 (en) Internet protocol telephony security architecture
CN109728909B (en) Identity authentication method and system based on USBKey
US7886345B2 (en) Password-protection module
JP4689815B2 (en) Data authentication method, message transmission method, and distributed system
KR101237632B1 (en) Network helper for authentication between a token and verifiers
EP0651533B1 (en) Method and apparatus for privacy and authentication in a mobile wireless network
EP1197032B1 (en) Server-assisted regeneration of a strong secret from a weak secret
EP1512307B1 (en) Method and system for challenge-response user authentication
US20060005033A1 (en) System and method for secure communications between at least one user device and a network entity
EP1994487A2 (en) Mutual authentication between two parties using two consecutive one-time passwords
US10263782B2 (en) Soft-token authentication system
RU2008118495A (en) METHOD AND DEVICE FOR ESTABLISHING A SAFE ASSOCIATION
EP1391073A1 (en) Use and generation of a session key in a secure socket layer connection
JP4783340B2 (en) Protecting data traffic in a mobile network environment
US7562224B2 (en) System and method for multi-session establishment for a single device
EP1320975B1 (en) Internet protocol telephony security architecture
CN114978773A (en) Single package authentication method and system
Srivastava et al. A review on remote user authentication schemes using smart cards
Chatterjee et al. A novel multi-server authentication scheme for e-commerce applications using smart card
US10979226B1 (en) Soft-token authentication system with token blocking after entering the wrong PIN
Chen et al. SSL/TLS session-aware user authentication using a gaa bootstrapped key
CN117081783A (en) Identity authentication method, system, terminal, medium and application under distributed network
WO2005038608A2 (en) Mass subscriber management
Oppliger et al. SSL/TLS Session-Aware User Authentication: A Lightweight Alternative to Client-Side Certificates
Chang et al. An enhanced password authentication scheme providing password updating without smart cards

Legal Events

Date Code Title Description
MK4 Application lapsed section 142(2)(d) - no continuation fee paid for the application