U.S. patent application number 11/028821 was filed with the patent office on 2005-06-02 for internet protocol telephony security architecture.
This patent application is currently assigned to General Instrument Corporation. Invention is credited to Medvinsky, Alexander.
Application Number | 20050120248 11/028821 |
Document ID | / |
Family ID | 34555153 |
Filed Date | 2005-06-02 |
United States Patent
Application |
20050120248 |
Kind Code |
A1 |
Medvinsky, Alexander |
June 2, 2005 |
Internet protocol telephony security architecture
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.
Inventors: |
Medvinsky, Alexander; (San
Diego, CA) |
Correspondence
Address: |
TOWNSEND AND TOWNSEND AND CREW, LLP
TWO EMBARCADERO CENTER
EIGHTH FLOOR
SAN FRANCISCO
CA
94111-3834
US
|
Assignee: |
General Instrument
Corporation
Horsham
PA
|
Family ID: |
34555153 |
Appl. No.: |
11/028821 |
Filed: |
January 3, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11028821 |
Jan 3, 2005 |
|
|
|
09668426 |
Sep 22, 2000 |
|
|
|
09668426 |
Sep 22, 2000 |
|
|
|
PCT/US00/02174 |
Jan 28, 2000 |
|
|
|
09668426 |
Sep 22, 2000 |
|
|
|
PCT/US00/09318 |
Apr 7, 2000 |
|
|
|
60128772 |
Apr 9, 1999 |
|
|
|
Current U.S.
Class: |
726/4 |
Current CPC
Class: |
H04M 7/0093 20130101;
H04L 29/06027 20130101; H04L 63/062 20130101; H04L 9/321 20130101;
H04L 63/061 20130101; H04M 3/387 20130101; H04M 7/0078 20130101;
H04L 63/12 20130101; G06F 21/606 20130101; H04L 63/0807 20130101;
H04W 12/122 20210101; H04L 9/3263 20130101; H04L 65/1069 20130101;
G06F 2211/008 20130101; G06F 12/1408 20130101; H04L 63/0442
20130101; H04W 12/121 20210101; H04M 3/38 20130101; G06F 2221/2129
20130101; G06F 2207/7219 20130101; H04L 65/1043 20130101; H04L
63/0435 20130101 |
Class at
Publication: |
713/201 |
International
Class: |
H04L 009/00 |
Claims
1. A method of providing key management comprising: providing a
server; providing a client configured to be coupled with said
server; providing a trusted third party configured to be coupled
with said client; allowing said server to initiate a key management
session with said client by conveying a server key management
message comprising a server_nonce to said client; receiving at said
server via said client a client key management response message
comprising a cryptographic message comprising a returned_nonce and
a ticket; determining if said client key management response
message should be accepted by said server by determining whether
said returned_nonce matches said server_nonce and whether said
ticket is validated.
2. The method as described in claim 1 wherein said allowing said
server to initiate said key management session with said client
comprises: providing said server_nonce at said server; generating
said server key management message at said server; conveying said
server key management message to said client.
3. The method as described in claim 2 and further comprising:
receiving said server key management message comprising said
server_nonce at said client; providing said returned_nonce at said
client; generating said key management response message at said
client comprising said returned_nonce; conveying said key
management response message comprising said returned_nonce to said
server.
4. The method as described in claim 3 and further comprising:
predetermining an out-of-bounds value for said returned_nonce to
prevent an attacker from simulating a server initiated key
management session; checking said returned_nonce to determine
whether the value of said returned_nonce is said out-of-bounds
value.
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 server to said client.
6. The method as described in claim 1 and further comprising:
receiving from said client an attacker induced response message
comprising a false_nonce at said server; determining that said
false_nonce is not equivalent to any valid nonce sent by said
server to said client; disregarding said client response message as
not being sent in response to a message sent by said server.
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 with said server; providing a key
distribution center configured to act as a trusted third party for
said client and said server; generating a server_nonce at said
server; generating a trigger message to trigger said key
management; coupling said trigger message with said server_nonce;
conveying said trigger message and said server_nonce to said
client; initiating a key management session by said server with
said client by utilizing said server_nonce coupled with said
trigger message; receiving at said server a client key management
response message comprising a returned_nonce and a ticket issued to
said client by said key distribution center.
8. (canceled)
9. The method as described in claim 7 and further comprising:
receiving said trigger message and said server_nonce at said
client; generating said client key management response message to
said trigger message at said client; conveying said client key
management response message comprising said returned_nonce to said
server from said client.
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. The method as described in claim 7 and further comprising:
receiving at said server said client key management response
message comprising a false_nonce from said client; determining that
said false_nonce does not match said server_nonce; determining that
said server did not initiate said key management session since said
false_nonce does not match said server_nonce.
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 with said
Signaling Controller; providing a key distribution center (KDC)
configured to be coupled with said signaling controller and coupled
with said KDC; issuing a ticket to said CTA by said 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
from said Signaling Controller to said CTA so as to initiate said
key management session by said Signaling Controller; generating a
response message to said trigger message comprising said ticket;
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
so as to confirm that said response message is in response to said
trigger message and not in response to a message sent to said
client by an attacker; transmitting an AP reply from said Signaling
Controller in reply to said response message; transmitting an SA
recovered message from said CTA to said Signaling Controller.
13. (canceled)
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 server_nonce
previously conveyed from said server to said client.
15. The method as described in claim 14 and further comprising:
determining that said client_nonce does not match said server_nonce
conveyed from said server; and then disregarding said AP
request.
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. The method as described in claim 14 and further comprising:
determining that said client_nonce does match said server_nonce
conveyed from said server; and generating an AP reply at said
server in response to said AP request.
18. A system for providing key management in a Kerberos based
system, said system comprising: a server; a client configured to be
coupled with said server; a key distribution center configured to
act as a trusted third party for said client and said server;
computer code coupled with said server operable to initiate a key
management session by said server with said client; computer code
coupled with said server operable to generate a server_nonce at
said server; computer code coupled with said server operable to
convey said trigger message and said server_nonce to said
client.
19. (canceled)
20. The system as described in claim 18 and further comprising:
computer code coupled with said client operable to generate a
response message to said trigger message; computer code coupled
with said client operable to convey said response message and a
returned_nonce to said server.
21. The system as described in claim 20 and further comprising:
computer code coupled with said server operable to confirm the
value of said returned_nonce at said server.
Description
[0001] This application claims priority from co-pending PCT
Application No. PCT/US00/09318 filed on Apr. 7, 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 Ser. No. 60/128,772 entitled, "Internet
Protocol Telephony Security Architecture" filed on Apr. 9, 1999, as
well as PCT Application No. PCT/US00/02174 filed on Jan. 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
[0002] 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.
[0003] 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.
[0004] 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
[0005] 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.
[0006] 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.
[0007] In addition, one embodiment can be implemented in code and
by circuitry operable to produce the acts of the method.
[0008] 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
[0009] FIG. 1 shows a flow chart demonstrating an overview of one
embodiment of the invention.
[0010] FIGS. 2A and 2B show a more detailed flow chart
demonstrating a key management session between a server and a
client.
[0011] FIG. 3 shows steps of a key management session after the key
management session is initiated.
[0012] FIG. 4 shows a general block diagram of a
client/server/trusted third party network.
[0013] 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.
[0014] 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
[0015] 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.
[0016] 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.
[0017] 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
returned_nonce, and the second nonce are conveyed to the server
244.
[0018] 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 returned_nonce 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 returned_nonce 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 returned_nonce does equal the
value of the nonce stored at the server, then the key management
session continues 260.
[0019] 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 (SA) recovered message to the server 372. This
completes the applicable Kerberos key management session.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
* * * * *