fig1 is a block diagram of the network elements associated with the method of the present invention as applied to a two - party session between calling party customer premises equipment ( cpe ) 10 and called party cpe 12 . calling party cpe 10 and called party cpe 12 are ip network thin client devices of the type known in the prior art to be used for ip applications such as voice communications . such devices are known in the art as “ thin clients ” because they contain limited processing and storage power . they are designed to provide an inexpensive means for users to connect to an ip network and to be provided with ip services . in fig1 calling party cpe 10 is connected via communications link 18 to ip network 14 . likewise , called party cpe 12 is connected via communications link 20 to ip network 14 . communications links 18 , 20 could be ethernet , cable modem , digital subscriber line ( dsl ), asynchronous transfer mode ( atm ) links , etc . ip network 14 is a packet switched data network . typically , ip network 14 could comprise at least a portion of the internet , or a private enterprise network , or virtual public network ( vpn ) over public facilities . though an ip network is illustrated , the present invention could work with any network where secure communications are required . key broker 16 is a personal computer or mini computer that may also manage the operation of thin client calling party cpe 10 and thin client called party cpe 12 via links 24 , ip network 14 and links 18 or 20 as the case may be . exemplary products that may be used to implement the key broker 16 include ibm rs / 6000 , sun microsystems sparc station , and hewlett packard hp 9000 , running an operating system such as microsoft windows nt . the key broker 16 possesses the processing power necessary to administer , control , process and manage the necessary applications through calling party cpe 10 and called party cpe 12 . this includes the processing power necessary to calculate encryption keys for use by calling party cpe 10 and called party cpe 12 , and may include as well the capability for testing , trouble reporting , configuration , installation , protocol translation , etc . the method of the present invention avoids unnecessary delay by pre - establishing a set of symmetric encryption keys ( i . e . “ session ” keys ) for immediate use by network elements such as calling party cpe 10 and called party cpe 12 . this set of encryption keys is used for both signaling and bearer channel authentication and protection . once an encryption key is used by a network element for a session ( such as a call ), the existing encryption key is then used to establish a fresh encryption key for the network element . the old key is then discarded . in this manner , these one - time session keys shared between network entities during the course of a session are immediately invalidated after the transaction is completed , thereby eliminating their use for unauthorized purposes . the chaining of secure key exchanges avoids time consuming open channel key exchanges by sending new keys over pre - secured channels . perfect forward security ( pfs ) can be provided by “ breaking the chain ” through periodic key refreshes during system idle times using prior art techniques . the dotted lines in fig1 are meant to represent a logical link to illustrate the negotiation and / or forwarding of keys between key broker 16 and calling party cpe 10 and called party cpe 12 , in accordance with the following methods described in relation to fig1 and 3 . in practice , the encryption keys used in accordance with the present invention would be negotiated and / or transmitted across communication links 18 , 20 and 24 , as the case may be . the method of the present invention comprises the following steps in the context of a two - party session between calling party cpe 10 and called party cpe 12 : 1 . key broker 16 negotiates keys k 1 & amp ; k 2 with calling party cpe 10 and called party cpe 12 respectively using any established prior art technique , such as ike , diffie - hellman , rsa , out of band methods such as pre - shared keys or passwords , etc .). in the preferred embodiment , this step is performed during a time of the day when session frequency is low in the network , or at some set initialization time . key broker 16 keeps a record of k 1 & amp ; k 2 . 2 . calling party cpe 10 initiates a communication session with called party cpe 12 across links 18 and 24 to key broker 16 . 3 . key broker 16 encrypts k 2 with k 1 ( shown as { k 2 } k 1 on the figure ) and transmits the encrypted data to calling party cpe 10 across communications links 24 and 18 . 4 . using k 1 , calling party cpe 10 decrypts k 2 . 5 . using k 2 , calling party cpe 10 encrypts session data , such as voice and forwards such encrypted data across communications links 18 and 20 to called party cpe 12 . 6 . using k 2 , called party cpe 12 decrypts the received session data . 7 . using k 2 , called party cpe 12 encrypts session data across communications links 20 and 18 to calling party cpe 10 . 8 . using k 2 , calling party cpe 10 decrypts the received session data . 9 . steps 5 through 8 are repeated until the session is terminated . 11 . key broker 16 encrypts k 3 with k 2 ( shown as { k 3 } k 2 on the figure ) and transmits the encrypted data to called party cpe 12 across communications links 24 and 20 . 12 . called party cpe , 12 uses k 2 to decrypt k 3 . 13 . called party cpe 12 discards k 2 and stores k 3 for use in the next session from calling party cpe 10 , or any other network entity . though it is preferred that the encryption key of the “ called ” party is forwarded to the “ calling ” party before session data is exchanged , the present invention can also work where the encryption key of the “ calling ” party is forwarded to the “ called ” party before session data is exchanged . as explained above , it is preferred that key broker 16 periodically refresh all encryption keys ( such as k 1 and k 2 or k 3 as the case may be ) during system idle times using prior art techniques . such refreshing of keys should preferably take place once every 24 hours . fig2 is a block diagram of the network elements associated with the method of the present invention as applied to a three - party session between calling party cpe 10 , called party cpe 12 and called party cpe 13 . all of the network elements and connections of fig1 remain unchanged , with the addition of communication link 21 between called party cpe 13 and ip network 14 . communications link 21 could be ethernet , cable modem , digital subscriber line ( dsl ), asynchronous transfer mode ( atm ) links , etc . the method of the present invention comprises the following steps in the context of a two - party session between calling party cpe 10 and called party cpe 12 : 1 . key broker 16 negotiates keys k 1 , k 2 & amp ; k 3 with calling party cpe 10 , called party cpe 12 , and called party cpe 13 respectively using any established prior art technique . in the preferred embodiment , this step is performed during a time of the day when session frequency is low in the network , or at some set initialization time . key broker 16 keeps a record of k 1 , k 2 & amp ; k 3 . 2 . calling party cpe 10 initiates a communication session with called party cpe 12 across communication links 18 and 24 to key broker 16 . 3 . key broker 16 encrypts k 2 with k 1 ( shown as { k 2 } k 1 on the figure ) and transmits the encrypted data to calling party cpe 10 across communications links 24 and 18 . 4 . using k 1 , calling party cpe 10 decrypts k 2 . 5 . the session proceeds as with steps 5 - 8 described above for the fig1 embodiment until either one of calling party cpe 10 and called party cpe 12 initiates a conference session to called party cpe 13 through key broker 16 . 6 . key broker 16 encrypts k 2 with k 3 ( shown as { k 2 } k 3 on the figure ) and transmits the encrypted data to called party cpe 13 across communications links 24 and 21 . 7 . using k 3 , called party cpe 13 decrypts k 2 . 8 . the session proceeds as with step 5 above for this fig2 embodiment with all parties using k 2 to encrypt and decrypt session data until the session is terminated . 10 . key broker 16 encrypts k 4 with k 2 ( shown as { k 4 } k 2 on the figure ) and transmits the encrypted data to called party cpe 12 across communications links 24 and 20 . 11 . called party cpe 12 uses k 2 to decrypt k 4 . 12 . called party cpe 12 discards k 2 and stores k 4 for use in the next session . persons skilled in the art will quickly understand how the above technique can also be used on a scaled basis to apply to four - way , five - way , etc . calls . due to the symmetric nature of the key exchange , this method applies equally where bearer channel servers exist , e . g . collaborative network application servers such as conference bridges . as with the description of fig1 the present invention applied to a three - way session ( and more ) can also work where the encryption key of the “ calling ” party is forwarded to both the “ called ” parties before session data is exchanged . as well , it is preferred that key broker 16 periodically refresh encryption keys k 1 , k 2 and k 3 ( or k 4 as the case may be ) during system idle times using prior art techniques . such refreshing of keys should preferably take place once every 24 hours . fig3 is a block diagram of the network elements associated with the method of the present invention as applied to a two - party session across two distinct ip networks , ip network a 14 and ip network b 54 connected by communications link 74 . key broker b 56 is connected to ip network b via link 70 , and called party cpe 52 is connected to ip network b 54 via link 60 . in this context , the method of the present invention comprises the following steps : 1 . key broker a 16 negotiates encryption key k 1 with calling party cpe 10 , and key broker b 56 negotiates encryption key k 3 with called party cpe 12 using any established prior art technique . in the preferred embodiment , this step is performed during a time of the day when session frequency is low in the network , or at some set initialization time . key broker a 16 keeps a record of k 1 and key broker b 56 keeps a record of k 3 . 2 . calling party cpe 10 initiates a communication session with called party cpe 52 across communication links 18 and 24 to key broker a 16 . 3 . key broker a 16 negotiates k 2 with key broker b 56 using prior art techniques across communication links 24 , 74 and 70 . 4 . key broker b 56 encrypts k 3 with k 2 ( shown as { k 3 } k 2 on the figure ) and transmits the encrypted data to key broker a 16 across communications link 70 , 74 and 24 . 5 . using k 2 , key broker a 16 decrypts k 3 . 6 . key broker a 16 encrypts k 3 with k 1 ( shown as { k 3 } k 1 on the figure ) and transmits the encrypted data to calling party cpe 10 across communications links 24 and 18 . 7 . using k 1 , calling party cpe 10 decrypts k 3 . 8 . using k 3 , calling party cpe 10 encrypts session data , such as voice and forwards such encrypted data across communications links 18 , 74 and 60 to called party cpe 52 . 9 . using k 3 , called party cpe 52 decrypts the received session data . 10 . using k 3 , called party cpe 52 encrypts session data across communications links 60 , 74 and 18 to calling party cpe 10 . 11 . using k 3 , calling party cpe 10 decrypts the received session data . 12 . steps 8 through 11 are repeated until the session is terminated . 13 . key broker b 56 calculates encryption key k 4 . 14 . key broker b 56 encrypts k 4 with k 3 ( shown as { k 4 } k 3 on the figure ) and transmits the encrypted data to called party cpe 52 across communications links 70 and 60 . 15 . called party cpe 52 uses k 3 to decrypt k 4 . 16 . called party cpe 52 discards k 3 and stores k 4 for use in the next session from calling party cpe 10 or any other network entity in either ip network a 14 or ip network b 54 . as explained above , it is preferred that key broker a 16 and key broker b 56 periodically refresh encryption keys k 1 and k 3 ( or k 4 as the case may be ) during system idle times using prior art techniques . such refreshing of encryption keys should preferably take place once every 24 hours . the present invention is typically implemented using a computer program product that forms part of a key broker and a cpe ( such as key broker 16 , and calling party cpe 10 and called party cpe 12 in fig1 ). appropriate computer program code in combination with such devices implements the steps of the present invention . this computer program code is often stored on a storage medium , such as a diskette , hard disk , cd - rom , or tape . the medium can also be a memory storage device or collection of memory storage devices such as read - only memory ( rom ) or random access memory ( ram ). fig4 illustrates one example of a storage medium . fig4 shows a tape cartridge of the type where magnetic medium 81 is enclosed in a protective cassette 82 . magnetic field changes over the surface of the magnetic media 81 are used to encode the computer program code . the above description of a preferred embodiment should not be interpreted in any limiting manner since variations and refinements can be made without departing from the spirit of the invention . the scope of the invention is defined by the appended claims and their equivalents .