Application-Level Service Access to Encrypted Data Streams

TECHNICAL FIELD

p-0002The present disclosure generally relates to processing encrypted application-level messages in a network node such as a router or switch.

BACKGROUND

p-0003The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

p-0004Data communication networks use services such as compression, latency reduction, intrusion prevention, data leakage, and firewalls. These services are required to act directly on the traffic that passes through them. Technical advances are resulting in services that have greater awareness of information represented in a message at the application layer of the OSI network reference model, or represented in a message payload, as compared to the network packet level. However, these services cannot inspect or modify information at the application level when the information is encrypted. This problem occurs for any encrypted stream or tunnel traversing one of these services.

p-0005Examples of cryptographic protocols that create this problem include SSL/TLS and IPsec. While these cryptographic protocols can provide a secure cryptographic connection between two devices, so that the secure channel is unintelligible to all other devices, there are situations in which it is desirable to allow other devices to listen in on a particular cryptographic connection. In many cases there is a need to monitor traffic for conformance to a security policy. Another situation is the need to debug a particular implementation using an external application such as tcpdump. The former case is especially important for network firewalls, which in some instances cannot perform their monitoring functions in the presence of encrypted traffic. Additionally, some firewall functions such as telephony require access to signaling traffic in order to work at all.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0006In the drawings:

p-0007<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a networked system of a client, trusted intermediate node, server, and key server.

p-0008<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a networked system in which trusted intermediate nodes communicate across a wide area network (WAN).

p-0009<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a system in which trusted intermediate nodes participate in a wide area application services (WAAS) network.

p-0010<figref idrefs="DRAWINGS">FIG. 4A</figref> illustrates a client and server determining a shared master secret.

p-0011<figref idrefs="DRAWINGS">FIG. 4B</figref> illustrates a client and server determining connection keys for encrypted connections.

p-0012<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a client and server establishing an encrypted connection and transferring encrypted application data.

p-0013<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a trusted intermediate node obtaining connection keys for an encrypted connection between a client and a server.

p-0014<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates two trusted intermediate nodes in a wide area network obtaining connection keys for an encrypted connection between a client and a server.

p-0015<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates a computer system upon which an embodiment may be implemented.

DETAILED DESCRIPTION

p-0016Application-level service access to encrypted data streams is now described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

p-0017Embodiments are described herein according to the following outline: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0017">1.0 General Overview</li><li id="ul0002-0002" num="0018">2.0 Structural and Functional Overview <ul><li id="ul0003-0001" num="0019">2.1 Secure Sockets Layer-Background</li><li id="ul0003-0002" num="0020">2.2 Trusted Intermediary Node Services</li><li id="ul0003-0003" num="0021">2.3 Benefits of Certain Embodiments</li></ul></li><li id="ul0002-0003" num="0022">3.0 Secure Key Share Transport for Monitoring IPsec Connections</li><li id="ul0002-0004" num="0023">4.0 Implementation Mechanisms—Hardware Overview</li><li id="ul0002-0005" num="0024">5.0 Extensions and Alternatives</li></ul></li></ul>

p-00181.0 General Overview

p-0019Techniques for securely providing cryptographic keys to trusted intermediate nodes or monitoring devices are described so that SSL, TLS, or IPSec communications can be monitored, compressed over a WAN, or otherwise used. In an embodiment, a trusted intermediate node comprises logic that is configured to establish a secure connection to a key server; receive or capture session identification data for an encrypted session between a client and a content server during negotiation of the encrypted session, and store a copy of the session identification data; request from the key server, over the secure connection, a decryption key associated with the encrypted session; receive or capture an encrypted message communicated between the client and the content server; forward the encrypted message without modification to the destination address of the encrypted message; and decrypt the encrypted message using the decryption key to result in decrypted data and to use or store the decrypted data for other data processing.

p-0020In an embodiment, the logic is further configured to perform compressing the decrypted data to result in creating compressed data; forwarding the compressed data across a wide area network to a trusted intermediate node. In an embodiment, the encryption protocol is Secure Sockets Layer (SSL). In an embodiment, the encryption protocol is Transport Layer Security (TLS). To perform such WAN optimization, a node is not required to receive an HMAC value for the connection, but can only receive a cipher key to facilitate decryption, followed by compression, decompression at a far-end node, and re-encryption. Further, the optimized message still can be guaranteed as authentic since the intermediary nodes did not receive the HMAC value. In other embodiments, local application optimization may occur at an edge node, and if such optimization involves a change in content, then the HMAC can be provided.

p-0021In an embodiment, the key server is co-located with the content server. In an embodiment, the first network and the one or more second networks each comprise different first and second local area networks respectively.

p-0022In an embodiment, the apparatus comprises a first trusted intermediate node configured at an edge location in a wide area network and wherein the key server is configured in a second trusted intermediate node at a core location of the wide area network. In one feature, the second trusted intermediate node and the content server are within a single domain.

p-0023In an embodiment, the session identification data comprises a source network address, a destination network address, a source port number, and a destination port number, all obtained from a transport control protocol (TCP) header of the message. These values are sometimes termed the TCP 4-tuple. Additionally or alternatively, a Secure Sockets Layer (SSL) session identifier may be used. In an embodiment, the logic configured for establishing a secure connection to the key server comprises logic configured for establishing an IPsec tunnel from the apparatus to the key server. Alternatively, the secure connection may comprise another SSL session.

p-0024In an embodiment, a data processing system comprises a content server comprising a key server, wherein one or both of the content server and the key server are configured with logic which when executed implements an encrypted data communication protocol; a first trusted intermediate node configured at an edge location of a wide area network and comprising: a first network interface that is configured to be coupled to a client computer; one or more second network interfaces that are configured to be coupled to the wide area network and to the key server; a second trusted intermediate node configured at an core location of the wide area network and comprising: a third network interface that is configured to be coupled to the content server; a fourth network interface that is configured to be coupled to the first trusted intermediate node through the wide area network; wherein the network interfaces are configured to receive and forward all data communicated between the client and the server; logic in each of the first trusted intermediate node and the second trusted intermediate node encoded in one or more computer-readable media for operation and configurable when executed operable to cause a processor in the node to perform: establishing a secure connection to the key server; receiving session identification data for an encrypted session between the client and the content server during negotiation of the encrypted session between the client and the content server using an encryption protocol, and storing a copy of the session identification data; communicating a plurality of messages relating to the negotiation between the first trusted intermediate node and the second trusted intermediate node using data compression, decompressing the plurality of handshake messages at the first trusted intermediate node and the second trusted intermediate node, and forwarding the decompressed handshake messages without modification to the client or the content server according to a destination address in the handshake messages; receiving a message from the content server indicating that the negotiation is finished; requesting from the key server, over the secure connection, a decryption key associated with the encrypted session; receiving an encrypted message communicated between the client and the content server in the encrypted session; forwarding the encrypted message without modification to the client or the content server according to a destination address in the encrypted message; decrypting the encrypted message using the decryption key to result in decrypted data and using or storing the decrypted data in a storage unit.

p-0025In an embodiment, a network monitoring apparatus comprises a first network interface that is configured to be coupled to a first endpoint computer through a first network; a second network interface that is configured to be coupled to a second endpoint computer through a second network; wherein the first network interface and second network interface are configured to receive and forward all data communicated between the first endpoint computer and the second endpoint computer; a processor; logic encoded in one or more computer-readable media for operation and configurable when executed operable to cause the processor to perform: sending a request message to one or more of the first endpoint computer and the second endpoint computer to provide an encryption key that the first endpoint computer and the second endpoint computer are using to encrypt data communicated in a cryptographic session between the first endpoint computer and the second endpoint computer; wherein the request message comprises a session descriptor that describes the cryptographic session; receiving, from one or more of the first endpoint computer and the second endpoint computer, a reply message comprising a keyshare or a key that can be used to decrypt the data communicated in the cryptographic session; wherein the reply session descriptor is encrypted; receiving an encrypted message communicated between the first endpoint computer and the second endpoint computer in the encrypted session; forwarding the encrypted message without modification to the first endpoint computer or the second endpoint computer according to a destination address in the encrypted message; decrypting the encrypted message using the decryption key to result in decrypted data and using or storing the decrypted data in a storage unit.

p-0026While one embodiment may use cipher keys, other embodiments may use any of the key types involved in a bi-directional SSL connection or session. For example, a bi-directional SSL session will use different cipher keys and HMAC values for upstream and downstream traffic. In an embodiment, the key server can provide a cipher key for decryption of upstream traffic without supplying the keys for decryption or authentication of downstream traffic. Further, the key server can provide cipher key(s) only, rather than both cipher and HMAC keys. Embodiments provide the flexibility to deliver one or several keys in any of many combinations, giving the key server fine-grained control over the trusted intermediate nodes on a per-session basis.

p-0027In other embodiments, the invention encompasses computer-implemented methods and computer-readable media.

p-00282.0 Structural and Functional Overview

p-00292.1 Secure Sockets Layer—Background

p-0030Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are successful encryption protocols that are widely used in data communications over public networks and internetworks, such as the public Internet. SSL streams are widely used to support confidential, authenticated communications between clients and hypertext transfer protocol (HTTP) or World Wide Web applications. In an embodiment, trusted intermediate nodes enable inspection, use and modification of SSL streams while maintaining end-to-end authentication and authenticity.

p-0031This document assumes that a reader is familiar with SSL. Detailed descriptions of SSL are provided in <i>SSL and TLS, Designing and Building Secure Systems </i>by Eric Rescorla and in <i>Network Security with OpenSSL </i>from O'Reilly. The online encyclopedia wikipedia.org has, at the time of this writing, a comprehensive article on Transport Layer Security. A detailed description of the SSL security model is found in Wanger et al., “Analysis of the SSL 3.0 protocol,” available online at the time of this writing in the document “paper-ssl.pdf” at the domain schneier.com on the World Wide Web. The present description reviews some aspects of SSL that are most pertinent to the solutions described herein.

p-0032SSL makes communication secure, by encrypting traffic and thereby keeping communications private. SSL also provides authentication and ensures the authenticity of a received message. Because SSL is usually used over arbitrary networks that both the user and the destination service do not control, SSL provides means by which a client can guarantee that a network site is genuine. Further, SSL provides means to guarantee that a message sent from the client to server, or the server to the client, is authentic and was not changed in transit.

p-0033With conventional SSL, only end points participate in a security negotiation. Nodes between the end points cannot participate in a connection, decrypt traffic, or modify encrypted messages. However, evolving network services need to act on application data streams. When the data streams are encrypted using SSL, network services deployed in intermediate nodes, and not in end points, cannot perform services on the data streams. For example, a business enterprise may use a WAN link to connect branch offices to a headquarters, and effective application level compression techniques are available to increase the performance of the WAN links. However, SSL messages cannot be modified in transit, and therefore SSL messages traversing an application-level compression node cannot be optimized.

p-0034Past approaches to the problem generally have focused solely on the encryption attribute of the data stream, such techniques render a receiver unable to perform authentication and authenticity checks on par with an uninterrupted SSL connection. Past approaches include SSL Termination techniques and Connection Key Derivation (CKD) techniques. In SSL termination techniques, an SSL session is terminated at an Intermediary Service (IS) prior to the intended Destination Service (DS). The terminating device directly generates and responds to SSL handshake requests to and from the client. If a back-end SSL connection is required, then the IS acts as a client creating a new SSL connection to the DS. The IS often proxies the application traffic between the two SSL sessions. However, in termination techniques, end-to-end cryptographically strong authentication is not workable, because at best the client can authenticate the IS, but not the DS. Further, validation problems can occur if the IS presents a credential that uses a certificate authority (CA) previously unknown to the client. This is commonly cause by the IS having a self signed certificate versus one from a well known signing authority.

p-0035Still further, termination techniques disrupt SSL's end-to-end authenticity capability. The client must “trust” that the IS delivers its messages unchanged to the DS, because the client negotiates the hashed message authentication codes (HMACs) that are used to sign a message with the IS, rather than the DS. Conversely, the DS must “trust” that the IS delivers its messages unchanged to the client. End-to-end authentication is not possible, and the IS could intentionally modify content or innocently deliver incorrect content due to errors in configuration or implementation.

p-0036Termination techniques suffer from numerous other drawbacks including the inability to perform an end-to-end audit of a connection's trust properties; problems arising when revocation of digital certificates is necessary; the inability to limit the content of a message that the IS can access; challenges in arriving at the correct cipher suite; performance issues arising from the need to perform both decryption of inbound traffic and re-encryption of outbound traffic at the IS; deployment challenges such as certificate distribution;

p-0037Connection Key Derivation techniques are based on an understanding of how the SSL Master Secret and connection secrets are derived, and effectively provide an IS without terminating SSL. Using access to the private key of the destination service and by inspecting SSL handshake messages, a CKD solution can derive first the Master Secret and subsequently the keys for a specific connection. One example of connection key derivation (CKD) is the SSL plug-in for the open source packet sniffing tool WireShark, also known as Ethereal. Another example is IntruShield from McAfee. In one interpretation of the use of CKD the client can be said to authenticate the IS and not the DS, since the IS has access to the private key of the DS and thus the IS has control over the content. Further, because the IS knows the private key of the DS, message authenticity is potentially compromised. Both the client and the DS must both “trust” the IS to deliver the correct site to the Client and to deliver the content correctly. Audit and traceability is a challenge using the CKD technique. Revocation of trust is difficult with CKD techniques. Access control to message content cannot be limited with CKD since the IS has access to the fundamental keys for all connections. Deployment is complicated, because the IS node's knowledge of the private key creates significant issues for revocation of trust, audit trail, and access control.

p-00382.2 Trusted Intermediary Node Services

p-0039<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a networked system of a client, trusted intermediate node, server, and key server. <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a networked system in which trusted intermediate nodes communicate across a wide area network (WAN). Referring first to <figref idrefs="DRAWINGS">FIG. 1</figref>, in an embodiment, a client <b>102</b> is coupled on a first connection <b>101</b> directly or indirectly through one or more networks <b>110</b> to a trusted intermediate node (TIN) <b>104</b>. Client <b>102</b> represents a computer of any kind including but not limited to a personal computer or wireless device. TIN <b>104</b> comprises a network node such as a router or switch, or a general-purpose computer not forming an element of network infrastructure, which is configured with logic that implements the functions described further herein.

p-0040TIN <b>104</b> has a second connection <b>105</b> to server <b>106</b>, which represents an application server or other network resource that the client <b>102</b> seeks to access. TIN <b>104</b> is also coupled to a key server <b>108</b> by a third connection <b>103</b> that is logically separate from the connections of the TIN to the client <b>102</b> and to the server <b>106</b>. In some sections herein the server <b>106</b> is termed a “content server” but that term is used purely to disambiguate from the key server <b>108</b>, and the server <b>106</b> may serve any functional purpose not necessarily related to delivering content. The key server <b>108</b> is a logical entity that may comprise a process or software element hosted on server <b>106</b>; a separate computer is not required to implement the key server.

p-0041The third connection <b>103</b> is a secure connection between the TIN <b>104</b> and the key server <b>108</b>, and the third connection is established before the TIN begins processing messages between the client <b>102</b> and the server <b>106</b>. The third connection <b>103</b> forms a secure side channel between the TIN <b>104</b> and the key server. The third connection <b>103</b> is configured using high grade authentication and privacy. For example, the third connection <b>103</b> is configured as an IPsec tunnel from the TIN <b>104</b> to the key server <b>108</b>.

p-0042In the approach herein, an intermediary node such as TIN <b>104</b> can request and receive individual connection keys using a secure side channel between the TIN <b>104</b> and key server <b>108</b>. The TIN <b>104</b> has no capability to calculate keys on its own. In all cases, TIN <b>104</b> uses the secure side channel to obtain the connection keys. The key server <b>108</b> may determine, based on stored policy, to provide only particular keys for a session or connection. For example, the key server <b>108</b> can provide an downstream cipher key alone to enable the TIN <b>104</b> to decrypt a data payload going from content server to client, a cipher key as well as an authentication (HMAC) key, or other combinations of key material of each direction upstream and downstream.

p-0043In an embodiment, the key server <b>108</b> comprises a connection key distribution service, denoted as Trusted Intermediary Node Key Service, at server <b>106</b>, TIN <b>104</b>, or another node. The Trusted Intermediary Node Key Service selects and serves unique connection keys such as client cipher key, server cipher key, client HMAC, etc., to the TIN <b>104</b>. Multiple different trusted intermediary nodes <b>104</b>, in different locations, can access the Trusted Intermediary Node Key Service to obtain connection keying material.

p-0044In an embodiment, only the server <b>106</b> needs direct access to the private key of a credential, which the server already holds in a conventional SSL scenario. The server <b>106</b> and the key server <b>108</b> may be co-located, and the key server may be implemented as a service running on the server <b>106</b>. In such an arrangement, the key server <b>108</b> may obtain session keys that the server <b>106</b> negotiates with the client <b>102</b> using programmatic calls or other communications that do not traverse a network. As a result, the key server <b>108</b> acquires all keys that are negotiated. In an embodiment, the Trusted Intermediary Node Key Service comprises a policy engine that determines or gates which connection keys are distributed, and which nodes are allowed to receive connection keys.

p-0045In operation, the Client <b>102</b> makes a SSL handshake request towards the server <b>106</b>. The TIN <b>104</b> is in the path of connection and keeps track of the connection progress but does not disrupt the handshake. In particular, the TIN <b>104</b> captures the values for the transmission control protocol (TCP) 4-tuple that uniquely define this connection and makes a request to the key server <b>108</b> on a side channel on connection <b>103</b>. The TIN <b>104</b> provides the TCP 4-tuple in its request to the key server <b>108</b>. The key server <b>108</b> supplies the TIN <b>104</b> with the appropriate connection keys for the SSL connection associated with the TCP 4-tuple, so that the TIN can decrypt the encrypted SSL stream and access information therein. Various other identifiers may be provided in the request to key server <b>108</b>, such as SSL Session Id, for certain complex network topographies.

p-0046<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an alternative arrangement in which a client <b>102</b> is coupled to local network <b>112</b>, to which a first TIN <b>104</b>A is coupled. The first TIN <b>104</b>A is also coupled over a wide area network (WAN) <b>114</b> to a second TIN <b>104</b>B, which is further coupled to a second LAN <b>116</b>. A server <b>106</b> and key server <b>108</b> are coupled to the second LAN <b>116</b>. In this arrangement, TIN <b>104</b>A, <b>104</b>B can perform compression of traffic on the SSL connection between the client <b>102</b> and the server <b>106</b> to reduce bandwidth consumed in communications over the WAN. The key server <b>108</b> may provide only a cipher key and not HMAC keys, which enables the TIN <b>104</b>A, <b>104</b>B to compress and decompress the data stream, but guarantees that endpoints receive authentic data without any need to establish a trust relationship with the TIN nodes. As the WAN may be coupled using slow network links, this approach improves throughput and speed of communication between the client <b>102</b> and the server <b>106</b>. Alternatively, the key server may provide, in addition to cipher keys, the HMAC keys to TIN <b>104</b>A, enabling TIN <b>104</b>A to perform local traffic optimization functions, such as server images from cache, etc.; receiving the HMAC keys enables TIN <b>104</b>A to re-sign the data payloads after performing such functions.

p-0047In operation of <figref idrefs="DRAWINGS">FIG. 2</figref>, both the TIN <b>104</b>A, <b>104</b>B operate as described above for <figref idrefs="DRAWINGS">FIG. 1</figref>. Thus, both the TIN <b>104</b>A, <b>104</b>B observe the SSL handshake of the client and server, capture and store TCP 4-tuple values, request connection keys from the key server <b>108</b> using the 4-tuple values, and receive the connection keys. The first TIN <b>104</b>A can decrypt traffic that the client <b>102</b> has encrypted, compress the traffic, and pass the traffic in compressed form to the second TIN <b>104</b>B. The second TIN <b>104</b>B can decompress the traffic, re-encrypt the traffic using the connection keys, and forward the encrypted traffic to the server. Authentication of the traffic is maintained because the TIN nodes are trusted and do not modify the traffic other than to compress it.

p-0048<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a system in which trusted intermediate nodes participate in a wide area application services (WAAS) network. In an embodiment, client <b>102</b> comprises a browser <b>302</b> that is coupled to a TIN <b>104</b> in an edge position of a WAAS network. The TIN <b>104</b>A hosts a TIN client <b>308</b> that is logically coupled to a key server <b>108</b> that is integrated into a TIN <b>104</b>B in the WAAS core. TIN <b>104</b>B is coupled to HTTPS server <b>304</b>, and both the TIN <b>104</b>B and HTTPS server are within a single administrative and security domain <b>306</b>. In this arrangement, browser <b>302</b> can establish a conventional control path to server <b>304</b> for communicating HTTP transfers. TIN client <b>308</b> of TIN <b>104</b>A maintains a logical side channel <b>310</b> to key server <b>108</b>. Accordingly, TIN <b>104</b>A can request and receive decryption keys or other keys from the key server <b>108</b> on side channel <b>310</b>, and TIN <b>104</b>B can obtain such keys directly from the key server, e.g., by an API call or other programmatic action.

p-0049The logical side channel <b>310</b> is established between the TIN <b>104</b>A and TIN <b>104</b>B using a separate security mechanism before browser <b>302</b> and HTTPS <b>304</b> begin a session. For example, TIN <b>104</b>A and TIN <b>104</b>B can establish an IPSec tunnel as the logical side channel <b>310</b> as part of a bootstrap loader sequence when the TIN nodes start up.

p-0050<figref idrefs="DRAWINGS">FIG. 4A</figref> illustrates a client and server determining a shared master secret. In an embodiment, in step <b>1</b> the client sends a random value to the server. The server responds at step <b>2</b> and provides a server random value, digital certificate and public key. In response, at step <b>402</b> the client selects a pre-master secret value and encrypts the pre-master secret using the public key received from the server. The client then sends the encrypted pre-master secret to the server at step <b>3</b>.

p-0051In steps <b>404</b> and <b>406</b>, which occur relatively concurrently, the client and server each privately compute a master secret value, which is the output of a key derivation function (KDF) that receives the client random value, server random value, and pre-master secret value as inputs. As a result, at step <b>408</b>, both the client and the server derive the same master secret for use in a communication session between the client and the server. However, keys for individual SSL connections within the session, each typically associated with a TCP connection between the client and server, are computed later when a connection initiates.

p-0052<figref idrefs="DRAWINGS">FIG. 4B</figref> illustrates a client and server determining connection keys for encrypted connections. After completing the steps of <figref idrefs="DRAWINGS">FIG. 4A</figref>, the client and server may establish a first TCP connection. To secure data transmitted on the connection, the client and server each independently compute a connection key, which is the output of the key derivation function based on input comprising the client random value, the server random value, the master secret, and a first label, as shown in step <b>410</b>, <b>412</b>. The label may be a sequence number or other value associated with the TCP connection. As a result, a first encrypted TCP connection <b>414</b> is established. Data transferred over the connection is encrypted using the first connection key.

p-0053As shown in steps <b>416</b>, <b>418</b>, any number of additional connection keys may be independent derived by each of the client and the server to form one or more additional encrypted TCP connections <b>420</b>.

p-0054<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a client and server establishing an encrypted connection and transferring encrypted application data. In an embodiment, the client and server perform a three-way TCP handshake <b>501</b>. In step <b>502</b>, the client sends a Client Hello message <b>502</b> containing the client random value. In response, the server sends a Server Hello message <b>504</b> containing the server random value and a cipher value, a Certificate message <b>506</b> that contains a digital certificate for the server, and a Server Hello Done message <b>508</b> announcing that the server has sent the preceding items.

p-0055In response, the client selects the pre-master secret value at step <b>510</b>, encrypts the pre-master secret with the server public key and sends the encrypted pre-master secret to the server in a Client Key Exchange message <b>512</b>.

p-0056In step <b>514</b> and step <b>516</b>, the client and server each independently compute the same master secret value. The client and server also each independently compute one or more client connection keys, IV, MAC, and server connection keys, IV, and MAC. The client may determine that it wants to use a different cipher, for purposes of encrypting data on connections with the server, than the cipher identified in the Server Hello message <b>504</b>, or may agree to use the cipher that was identified. The client sends a Change Cipher Spec message <b>520</b> that identifies the selected cipher. The client also sends a Finished message <b>524</b> that is encrypted using the connection key and signed with the MAC.

p-0057In response, the server determines whether the proposed cipher is acceptable. The server sends to the client a Change Cipher Spec message <b>526</b> that identifies the finally selected cipher. The server also sends a Finished message <b>528</b> that is encrypted and signed with the server MAC.

p-0058At this point the client and server can exchange one or more application data messages <b>530</b>, each of which is encrypted and framed in SSL records. To close the connection, the client can send an Alert message <b>532</b>.

p-0059<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a trusted intermediate node obtaining connection keys for an encrypted connection between a client and a server. In step <b>602</b>, client <b>102</b> and server <b>306</b> perform a conventional TCP 3-way handshake and an SSL handshake as described above. As a result, a TCP 4-tuple of values is selected and an SSL session identifier x is selected.

p-0060Messages involved in the TCP handshake and SSL handshake pass through the TIN <b>104</b>. In step <b>604</b>, the TIN <b>104</b> observes and stores the TCP connection 4-tuple of values and the SSL session identifier. TIN <b>104</b> now has enough information to make a request to the key server <b>610</b> for connection keys.

p-0061In step <b>608</b>, the TIN <b>104</b> sends a Get Connect Keys request message to a Key Discovery Service <b>610</b> associated with server <b>306</b>. The Key Discovery Service <b>610</b> is implemented, in one embodiment, as a web service that is compatible with other Web Services protocol definitions. In an embodiment, the Get Connect Keys request message provides the TCP 4-tuple of values, and optionally the SSL session identifier. The Get Connect Keys message is sent over a trusted channel <b>607</b> that is used for all key requests and responses for a session. Obtaining the connection keys is indeterminate especially with respect to time and policy. The TIN <b>104</b> can handle the ambiguity a variety of ways. The most graceful is for the TIN <b>104</b> to stall the Server Finished handshake message. The SSL handshake is not deemed complete until this Finished Message is received and process successfully by the client.

p-0062Alternatively, TIN <b>104</b> may elect to allow encrypted message traffic to occur up to a arbitrary amount storing the traffic for later decryption when the keys arrive. This approach is useful to address certain operational issues that may arise when available cryptography software is used in an implementation. For example, the client finished message is sent encrypted, but in the commonly-used cryptography library known as OpenSSL, server-side connection keys are not generated until the client finished message actually arrives. Thus, the keys are not available for the TIN when it first receives the client finished message. If the TIN did not forward the client finished message until it had the keys, then the keys would never be created; therefore, in an embodiment, the TIN stores the client finished message but also sends the message. Storing the message enables data in the message to be processed in the crypto engine of the TIN to keep the crypto engine synchronized. As an extension, an arbitrary amount of data can be allowed to flow even if keys are not present, which overcomes the problem of a connection stalling due to delays in getting keys. This approach may be useful in low-latency situations as a tradeoff between inspection and performance.

p-0063In response, Key Discovery Service <b>610</b> determines whether to provide keys to the TIN <b>104</b>. If the determination is positive, then the Key Discovery Service <b>610</b> provides one or more connection write keys, IV values, or MAC values in a response message <b>612</b> that is sent over the trusted channel <b>607</b>. Based on stored policy, the Key Discovery Service <b>610</b> can determine whether to provide a cipher key, an HMAC key, or both, for each connection or session. The TIN <b>104</b> then begins processing SSL records at step <b>614</b>. For example, the TIN can use the received keys to decrypt payloads and inspect payload contents, copy payload contents to other systems, perform WAN compression or decompression, etc.

p-0064As shown in step <b>620</b>, the same keys, IVs and MACs can be used for other messages which are exchanged on the same connection. The TIN <b>104</b> can maintain SSL state data for client-facing traffic and server-facing traffic. Further, as shown in step <b>622</b>, the TIN <b>104</b> can modify data in transit and cause the traffic to diverge to another node. In this case each message will have to be resigned by the appropriate HMAC key prior to re-encryption.

p-0065During the processing of SSL records by the TIN <b>104</b>, the previously selected TCP 4-tuple and SSL session identifier x are used at step <b>616</b> in messages from the TIN to the client and at step <b>618</b> in messages from the TIN to the server. Therefore, as stated at step <b>624</b>, the client and all network services other than the TIN receive uninterrupted TCP sequence values and SSL session information as originally set up. Further, as stated at step <b>626</b>, the SSL head end at server <b>306</b> and all network services other than the TIN receive uninterrupted TCP sequence values and SSL session information as originally set up. As a result, client <b>102</b> and server <b>306</b> can continue to communicate using an end-to-end SSL connection even though the TIN <b>104</b> is able to decrypt, inspect and use payload contents, or perform WAN compression with decryption and re-encryption performed in different TINs on either side of the WAN. Moreover, the use of TCP is not required and the particular values of the TCP variables are not important; embodiments are operable independent of TCP processing, which may use proxies, network address translation, or other processing without affecting operation of an embodiment.

p-0066<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates two trusted intermediate nodes in a wide area network obtaining connection keys for an encrypted connection between a client and a server. <figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a process involving the elements shown in <figref idrefs="DRAWINGS">FIG. 2</figref> comprising a client <b>102</b>, WAN edge TIN <b>104</b>A, WAN core TIN <b>104</b>B, and server <b>306</b>.

p-0067In step <b>602</b>, client <b>102</b> and server <b>306</b> perform a conventional TCP 3-way handshake and an SSL handshake as described above. As a result, a TCP 4-tuple of values is selected and an SSL session identifier x is selected.

p-0068Messages involved in the TCP handshake and SSL handshake pass through each of the TINs <b>104</b>A, <b>104</b>B. In step <b>604</b>A, the TIN <b>104</b>A observes and stores the TCP connection 4-tuple of values and optionally the SSL session identifier.

p-0069TIN <b>104</b> now has enough information to make a request to the key server <b>610</b> for connection keys.

p-0070In step <b>606</b>A, the TIN <b>104</b>A sends a Get Connect Keys request message to a Key Discovery Service <b>610</b> associated with server <b>306</b>. The Get Connect Keys message is sent over a trusted channel that is used for all key requests and responses for a session. The TIN <b>104</b>B can request the same keys in a similar manner by sending a separate Get Connect Keys request message at step <b>606</b>B.

p-0071In response to each of the messages <b>606</b>A, <b>606</b>B, Key Discovery Service <b>610</b> determines whether to provide keys to the requesting TIN <b>104</b>A, <b>104</b>B. If the determination is positive, then the Key Discovery Service selects and provides one or more connection write keys, IV values, or MAC values in separate response messages that are sent over the trusted channel. Based on stored policy, the Key Discovery Service <b>610</b> can determine whether to provide a cipher key, an HMAC key, or both, for each connection or session. Each TIN <b>104</b>A, <b>104</b>B then begins processing SSL records at step <b>614</b>A, <b>614</b>B. For example, each TIN <b>104</b>A, <b>104</b>B can use the received keys to decrypt payloads and inspect payload contents, copy payload contents to other systems, perform WAN compression or decompression, etc. Obtaining the connection keys is indeterminate especially with respect to time and policy. The TIN <b>104</b>A &amp; <b>104</b>B can handle the ambiguity a variety of ways. The most graceful is for the TIN <b>104</b>A &amp; <b>104</b>B to stall (temporarily delay forwarding) the Server Finished handshake message. The SSL handshake is not deemed complete until this Finished Message is received and process successfully by the client. Alternatively TIN <b>104</b> may elect to allow encrypted message traffic to occur up to a arbitrary amount storing the traffic for later decryption when the keys arrive.

p-0072As shown in step <b>620</b>A, <b>620</b>B, the same keys, IVs and MACs can be used for other messages which are exchanged on the same connection. Each TIN <b>104</b>A, <b>104</b>B can maintain SSL state data for WAN-facing traffic and for either client-facing traffic or server-facing traffic depending on the position of the TIN with respect to the WAN.

p-0073Further, as shown in step <b>704</b>, the TINs <b>104</b>A, <b>104</b>B can cooperate to optimize traffic carried within the WAN segment, using the same TCP 4-tuple and SSL session ID values as used on the exterior connections to the client and the server.

p-0074During the processing of SSL records by the TIN <b>104</b>, the previously selected TCP 4-tuple and SSL session identifier x are used at step <b>616</b> in messages from the TIN <b>104</b>A to the client and at step <b>618</b> in messages from the TIN <b>104</b>B to the server. As stated at step <b>702</b>, the data segment received at the client and the data segment received at the server <b>306</b> are identical streams of data even if WAN optimization is performed in the WAN interior at step <b>704</b>. This behavior creates the opportunity to supply TIN <b>104</b>A &amp; <b>104</b>B with cipher keys only. Since the original message sent by client or server is the same as the message received by server or client the original HMAC is still valid. Thus the TIN <b>104</b>A and <b>104</b>B have no requirement to have access to the HMAC keys.

p-00752.3 Benefits of Certain Embodiments

p-0076Using the approach herein, the Client <b>102</b> can authenticate to the server <b>106</b> unhindered by the TIN in the connection chain. The Client <b>102</b> in a cryptographically strong way is able to authenticate the server <b>106</b>, not some impersonation of the server <b>106</b>. Such end-to-end authentication is enabled by the SSL handshake occurring directly between the Client <b>102</b> and server <b>106</b> without involvement of a proxy. Server <b>106</b> has access to the private key of the Credential and therefore server <b>106</b> is the only entity that can “prove” its identity to the Client <b>102</b> in a cryptographically strong manner.

p-0077Further, using the approach herein a connection between the Client <b>102</b> and server <b>106</b> can only be started with a cryptographically strong authentication of the server <b>106</b> by the Client <b>102</b>. Consequently, the approach herein provides authentication equivalent to that of an unmodified SSL connection.

p-0078The Credentials authenticated by the Client <b>102</b> are obtained directly from the server <b>106</b>. Thus the Client <b>102</b> has the correct information to validate the Credential and make informed decisions on whether to proceed with the connection or not. Further, since the Credential is from the server <b>106</b>, no new complexity is introduced with respect to the use of a certificate authority.

p-0079Client side certificates work seamlessly with the approach herein because the SSL handshake is carried out end-to-end between the Client and server <b>106</b>. Client credentials are incorporated in the primary messages of the SSL handshake with the information ultimately hashed into the HMACs of the finished messages. Thus client side certificates are only supported when the handshake is end-to-end.

p-0080The present approach supports audit and traceability. From the perspective of Client <b>102</b>, the connection is from the server <b>106</b> with no indication that a TIN may be in the path. An audit trail accurately represents authentication, namely that the Client has initiated a connection with the server <b>106</b> and not with an impersonator. Further, the approach herein improves the ability to audit the server <b>106</b>, because the server is responsible to provide individual connection keys to a TIN and the server can track such distribution.

p-0081The approach herein also can accommodate the capability of SSL to authenticate messages with a hashed message authentication code (HMAC).

p-0082In an embodiment, the HMAC keys that are used for handshake authenticity are the same as those used for application data authenticity. Further, separate HMAC keys are used for messages generated by the server <b>106</b> and messages generated by the Client <b>102</b>. Individual handshake messages carry no authenticity information, yet at the end of the handshake, using a “client finished message” and a “server finished message,” the client and server each create an authenticity signature that incorporates all of the messages that have been part of the conversation to that point. The purpose of the authenticity signature is to protect against replay attacks and downgrading attacks if an unintentionally weak cipher is chosen for an otherwise well formed connection. The SSL protocol requires that the “client finished message” shall be sent and processed prior to the “server finished message”. Once the handshake is complete each individual message from client or server carries a HMAC code created using the HMAC key guaranteeing authenticity of the message regardless of message type.

p-0083The approach herein does not affect this process, if HMAC keys are not distributed using the key server <b>108</b>. When HMAC keys are not distributed to a TIN, then messages are guaranteed to delivered, unchanged, from client to server and from server to client. However, in an alternate embodiment, HMAC keys may be distributed from the key server <b>108</b> to a TIN.

p-0084When the server <b>106</b> has received the “client finished message” from client <b>102</b>, the server <b>106</b> is guaranteed that the handshake is authentic. However, to reach the same confidence level, the Client must receive the “server finished message” from the server <b>106</b>. Ideally, the server <b>106</b> would wait until the Client <b>102</b> has received this message prior to handing out the server HMAC key via key server <b>108</b>. However, the only way that server <b>106</b> can determine that this message has been received by the Client <b>102</b> is when the server <b>106</b> receives the next message from the Client, and the next message usually contains encrypted application data.

p-0085Providing the server HMAC key to a TIN prior to the Client processing the server finished message creates a risk that the “server finished message” could be modified in flight to take into account some other change that was previously spoofed onto the Client. The spoofing of an earlier handshake message would have been identified by the server <b>106</b> when it processed the client finished message, because the Client record of what was sent and received would not match the record of what the server <b>106</b> sent and received up to that point. Replay is not an issue since the Client always selects a variable called the “client random” at the beginning of each connection making it immune to replay attacks. Further at the point after the client has sent the “client finished message” the client only is awaiting a valid “server finished message”. Even though a TIN may have the server HMAC key prior to this message traversing it, and thus would have the ability to modify the message, the client is in a state in which only the real “server finished message” from the server will allow the connection to proceed. Further, implicit in providing a HMAC key to a TIN is the understanding from the server that messages may be modified, thus trust has been granted.

p-0086As previously stated, in conventional SSL, each application message between the Client and server <b>106</b> carries an individual HMAC for authenticity. In various embodiments, the key server <b>108</b> can provide HMAC keys in various ways. In one embodiment, key server <b>108</b> provides only the server HMAC key to a TIN. In another embodiment, key server <b>108</b> provides only the client HMAC key to a TIN. In other embodiments, both of the HMAC keys or neither HMAC key is provided to the TIN. When a HMAC key is not given out, the message traffic authenticated with that key is guaranteed to be unchanged end-to-end period. When HMAC key(s) are distributed a TIN may change the message payload as needed and resign the message such that the receiving side will accept the message as authentic. If HMAC keys are supplied to a TIN then the corresponding Cipher key must be supplied as HMAC keys can only act on decrypted data.

p-0087In an embodiment, server <b>106</b> controls the keys that it provides for each connection. When the server <b>106</b> stops providing keys, a TIN cannot intercept traffic. Therefore, the server <b>106</b> can control revocation of trust in the approaches herein. Keys that have been served out on an ongoing connection cannot be revoked. If HMAC keys have not been given out, then one side can stop communication and the other side will not be able to accept more messages. Such an approach does not preclude the one side from continuing to send traffic until a response is needed from the other side. If HMAC keys have been given out then it is possible that a TIN could mask a disconnect from one side to the other.

p-0088The server <b>306</b> in cooperation with the key server <b>610</b> also can control access to keys in a fine-grained manner. Available keys include keys for a server cipher, client cipher, server HMAC, and client HMAC. Some ciphers require an initialization vector (IV), and for such a cipher the IV is provided with the associated client or server cipher key. For example, assume that a TIN <b>104</b> is required to inspect outbound traffic for policy compliance to guard against “data leakage” from a business enterprise. The TIN <b>104</b> only needs the server cipher (and associated IV if any) to perform such a function, and therefore the key server <b>610</b> can provide only the server cipher to the TIN, accomplishing fine-grained control of key distribution. Assume further that the TIN <b>104</b> is only required to inspect traffic destined to a certain location. The server <b>306</b> and key server <b>610</b> can control key access by not issuing keys to connections that do not need to be accessed. For example, HMACs are not required in the foregoing scenarios, and therefore the server <b>306</b> and key server <b>610</b> should not distribute the HMACs but can provide only cipher keys.

p-0089In the WAN acceleration example of <figref idrefs="DRAWINGS">FIG. 2</figref>, the approach herein provides numerous benefits. One mode of WAN acceleration relies on deep stream compression. To perform this task the WAN devices that straddle the WAN <b>114</b>, such as TIN <b>104</b>A, <b>104</b>B of <figref idrefs="DRAWINGS">FIG. 2</figref>, need clear text access to the encrypted SSL stream. However, although the WAN segment is highly compressed, the LAN traffic to and from the Client <b>102</b> and server <b>106</b> on either side of the WAN <b>114</b> is received and arrives untouched. Therefore, key server <b>108</b> may only issue the cipher keys for TIN <b>104</b>A, <b>104</b>B to accomplish its task; in particular, the HMAC keys are not issued to the TINs. Accordingly, the approach herein allows WAN compression to occur, yet end-to-end authenticity is guaranteed; this combination is not possible in prior approaches.

p-0090The approach herein also results in using the correct cipher suite. A cipher suite selection process is part of the SSL handshake. Because the handshake is guaranteed to be authentic end-to-end, a TIN does not interfere with the cipher suite chosen by the Client <b>102</b> and server <b>106</b>.

p-0091The approach herein also requires fewer resources than prior techniques, because a TIN <b>104</b> does not need to perform public key-private key operations. For example, RSA decryption operations do not need to be done on the TIN <b>104</b>. A TIN <b>104</b> does perform bulk encryption of messages, and in some cases generates HMAC values and validates messages. Such operations do not require unusual resources and existing hardware platforms for a TIN, such as routers and switches, can be configured to support TIN operations using a software upgrade without adversely affecting performance.

p-0092Overhead and network traffic associated with the third connection <b>103</b> to the key server <b>108</b> is considered insignificant.

p-0093In an embodiment, server <b>106</b> is configured to support the approach herein and to implement a key server <b>108</b> as described herein. Alternatively, the key server <b>108</b> may be implemented in a separate network node that is configured to serve keys to a TIN <b>104</b> on behalf of the server <b>106</b>. The key server <b>108</b> can be located adjacent to the server <b>106</b>, and while adjacency is not required, co-location may strengthen the trust relationship of the key server <b>108</b> and the server <b>106</b>.

p-0094Embodiments can implement static keys or ephemeral keys in scenarios in which the client <b>102</b> performs authentication or uses client certificates, such as DSS or RSA certificates. Ephemeral keys can be fully supported using key server <b>108</b> co-located on server <b>106</b>. When the key server <b>108</b> is separate from the server <b>106</b>, then the key server has a man-in-the-middle role to accommodate the ephemeral keys.

p-0095The design does not modify the SSL protocol. As such existing clients, which are numerous, do not require modification and will interoperate with the approaches herein.

p-00963.0 Secure Key Share Transport for Monitoring IPsec Connections

p-0097In an embodiment, IPsec connections can be monitored by giving a monitoring entity, which may comprise a firewall, sniffer, or other network monitoring apparatus, access to a decryption key in a manner that is secure and that works with the multitude of cryptographic protocols that are currently used. For purposes of describing a clear example, this description assumes that the cryptographic session involves only two endpoints. Extensions to multipoint protocols can be accomplished in other embodiments. According to an embodiment:

p-00981) the monitor is not given the encryption keys without the consent of all of the participants in the cryptographic connection,

p-00992) the participants can authenticate the legitimacy of the monitoring request,

p-01003) the confidentiality of the keys is protected,

p-01014) the approach works with arbitrary key management and bulk encryption protocols, and

p-01025) it is possible to give the keys of a currently active session to the monitor.

p-0103In certain embodiments, one or more of these attributes may not be implemented. In an embodiment, the keys used to provide message authentication, entity authentication, and those used in key management are not provided to the monitor.

p-0104In an embodiment, a monitoring device requests encryption keys from endpoints. In an embodiment, after the endpoints have set up a cryptographic session (that is, after the key-management phase has completed), the monitoring device requests the session decryption keys from an endpoint, and does not allow session traffic from that endpoint to pass until it receives those keys. An endpoint can verify the authenticity of the requests from the monitor by verifying a digital signature that the monitor provides with its messages.

p-0105Further, confidentiality of the key that is provided back to the monitor can be provided by using public key encryption. For example, in one embodiment, an endpoint receives a public key of the monitor in advance, in a request message, or from a key registry. Only the monitor needs to have public keys. The endpoints need not be able to authenticate themselves to the monitor; the security assessment of the endpoints' traffic is done by the monitor using methods other than cryptographic authentication. Symmetric key encryption also can be used in other embodiments.

p-0106In an embodiment, a request message comprises: a session descriptor, which describes the cryptographic session that the monitor is interested in (e.g. address, port numbers, protocol); a random or pseudorandom nonce value; and a digital signature. Optionally, the request message may provide a public key of the monitor to the endpoint. Upon receiving such a request message, the endpoint verifies the digital signature, verifies that the endpoint is involved in the cryptographic session specified in the request, and determines whether to provide a key to the monitor. The endpoint then sends a reply message. These functions may be implemented in the endpoint in program logic of a security module, or program logic that implements a cryptographic protocol such as IPsec, SSL, TLS, etc.

p-0107In an embodiment, a reply message from an endpoint comprises a session definition structure that has been encrypted using the monitor's public key. The session definition structure contains either a key or a keyshare for each key in the protocol, and either the nonce sent in the first message or an error code. The error code is provided if the endpoint has determined not to consent to distribution of the key, or if the endpoint could not verify the digital signature.

p-0108An example session descriptor for the request message comprises a data structure having the following fields and values:

p-0109protocol: esp

p-0110spi: 0xdeadbeef

p-0111cipher: 3des

p-0112direction: sender

p-0113keyshare: NNN (arbitrary value or null)

p-0114An example session descriptor for the reply message is:

p-0115protocol: esp

p-0116spi: 0xdeadbeef

p-0117cipher: 3des

p-0118direction: receiver

p-0119keyshare: yyyyyyyyyyyyyyyyyyyy

p-0120In one embodiment, a particular public-key based key transport protocol is adapted to incorporate the request and reply protocol defined herein. Such an approach of adapting an existing protocol removes the burden of preparing a security proof for the adapted protocol. In various embodiments, the ANSI financial cryptography suite or IEEE P1363 may be used.

p-0121In one embodiment, optionally the monitor sends a request to both endpoints, and the protocol completes successfully only if both endpoints comply with the request. Successful completion can be constrained in this approach using a key splitting technique. In an embodiment, if an endpoint concurs with the request, then that endpoint sends a keyshare to the monitor. Given all of the keyshares, then the monitor can compute the key; without either one of the keyshares, the monitor has no information about the key. Using this approach, delivery of a key is conditioned on consent by both the endpoints.

p-0122In an embodiment, the key share approach computationally operates as follows:

p-01231. Let K=session key and let B=blinding value.

p-01242. Let S_a=K (+) B=key share of A

p-01253. Let S_b=B=key share of B

p-01264. The monitor computes K as S_a (+) S_b.

p-0127In an embodiment, the identities of A and B are unambiguous, so that a single device cannot be tricked into responding both as A and as B. In an embodiment, a role is assigned to a device as a part of the protocol definition. Alternatively, A can be denoted a ‘sender’ and B can be denoted a ‘receiver’; in this alternative, the A/B role would vary across the different key shares in each message (e.g. an ESP SA pair or TLS key set).

p-0128The blinding value is secret with respect to the endpoints. However, the key transport approach herein can be used in the absence of a method for establishing shared secrets dedicated for this purpose. In an embodiment, B is the output of a one-way hash function applied to K, e.g. B=SHA−1(K).

p-0129In this approach, distribution of keys is conditioned upon the consent of an endpoint. Embodiments are useful in various scenarios and applications, including but not limited to:

p-01301. a network in which there is no provision for security monitoring on the endpoints;

p-01312. a network in which cryptographic connections from less-trusted applications (e.g. VBSCRIPT, legacy systems) need to be allowed;

p-01323. a visitor to a corporate LAN making a cryptographic connection across the Internet to his home network. In this scenario, multiple trust domains exist. The visitor must reveal traffic to an inspection point on the host network in order to be allowed the connection; however, the visitor's traffic is still protected as it crosses the Internet.

p-0133Embodiments are workable through NAT/PAT when implemented in a NAT/PAT service on a firewall having the capability herein, but embodiments have limited utility in other NAT/PAT cases. In one embodiment, in a STUN-like approach, the endpoint sends out a UDP packet with the same port number as that of the cryptographic session in order to discover the proper port mappings.

p-0134In embodiment, to implement the dual-consent option with keyshares as described herein, both endpoints are configured to operate the protocol herein, and are configured to verify the public key of the firewall.

p-0135In one embodiment, two cryptographic sessions are established, comprising a different session between the firewall and each of the endpoints. In this approach, the firewall and each external endpoint must be able to authenticate each other, and must be configured to allow the connection. This approach would double the computational load of the firewall, and would increase the latency of the traffic.

p-01364.0 Implementation Mechanisms—Hardware Overview

p-0137<figref idrefs="DRAWINGS">FIG. 8</figref> is a block diagram that illustrates a computer system <b>800</b> upon which an embodiment of the invention may be implemented. The preferred embodiment is implemented using one or more computer programs running on a network element such as a router device. Thus, in this embodiment, the computer system <b>800</b> is a router.

p-0138Computer system <b>800</b> includes a bus <b>802</b> or other communication mechanism for communicating information, and a processor <b>804</b> coupled with bus <b>802</b> for processing information. Computer system <b>800</b> also includes a main memory <b>806</b>, such as a random access memory (RAM), flash memory, or other dynamic storage device, coupled to bus <b>802</b> for storing information and instructions to be executed by processor <b>804</b>. Main memory <b>806</b> also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor <b>804</b>. Computer system <b>800</b> further includes a read only memory (ROM) <b>808</b> or other static storage device coupled to bus <b>802</b> for storing static information and instructions for processor <b>804</b>. A storage device <b>810</b>, such as a magnetic disk, flash memory or optical disk, is provided and coupled to bus <b>802</b> for storing information and instructions.

p-0139A communication interface <b>818</b> may be coupled to bus <b>802</b> for communicating information and command selections to processor <b>804</b>. Interface <b>818</b> is a conventional serial interface such as an RS-232 or RS-422 interface. An external terminal <b>812</b> or other computer system connects to the computer system <b>800</b> and provides commands to it using the interface <b>814</b>. Firmware or software running in the computer system <b>800</b> provides a terminal interface or character-based command interface so that external commands can be given to the computer system.

p-0140A switching system <b>816</b> is coupled to bus <b>802</b> and has an input interface <b>814</b> and an output interface <b>819</b> to one or more external network elements. The external network elements may include a local network <b>822</b> coupled to one or more hosts <b>824</b>, or a global network such as Internet <b>828</b> having one or more servers <b>830</b>. The switching system <b>816</b> switches information traffic arriving on input interface <b>814</b> to output interface <b>819</b> according to pre-determined protocols and conventions that are well known. For example, switching system <b>816</b>, in cooperation with processor <b>804</b>, can determine a destination of a packet of data arriving on input interface <b>814</b> and send it to the correct destination using output interface <b>819</b>. The destinations may include host <b>824</b>, server <b>830</b>, other end stations, or other routing and switching devices in local network <b>822</b> or Internet <b>828</b>.

p-0141The invention is related to the use of computer system <b>800</b> for the techniques described herein. According to one embodiment of the invention, the techniques described herein are provided by computer system <b>800</b> in response to processor <b>804</b> executing one or more sequences of one or more instructions contained in main memory <b>806</b>. Such instructions may be read into main memory <b>806</b> from another computer-readable medium, such as storage device <b>810</b>. Execution of the sequences of instructions contained in main memory <b>806</b> causes processor <b>804</b> to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory <b>806</b>. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

p-0142The term “computer-readable medium” as used herein refers to any data storage medium that participates in providing instructions to processor <b>804</b> for execution. Such a medium may take many forms, including but not limited to non-volatile storage media and volatile storage media. Non-volatile storage media includes, for example, optical or magnetic disks, such as storage device <b>810</b>. Volatile storage media includes dynamic memory, such as main memory <b>806</b>.

p-0143Common forms of computer-readable storage media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other tangible storage medium from which a computer can read.

p-0144Various forms of computer readable storage media may be involved in carrying one or more sequences of one or more instructions to processor <b>804</b> for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system <b>800</b> can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus <b>802</b> can receive the data carried in the infrared signal and place the data on bus <b>802</b>. Bus <b>802</b> carries the data to main memory <b>806</b>, from which processor <b>804</b> retrieves and executes the instructions. The instructions received by main memory <b>806</b> may optionally be stored on storage device <b>810</b> either before or after execution by processor <b>804</b>.

p-0145Communication interface <b>818</b> also provides a two-way data communication coupling to a network link <b>820</b> that is connected to a local network <b>822</b>. For example, communication interface <b>818</b> may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface <b>818</b> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface <b>818</b> sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

p-0146Network link <b>820</b> typically provides data communication through one or more networks to other data devices. For example, network link <b>820</b> may provide a connection through local network <b>822</b> to a host computer <b>824</b> or to data equipment operated by an Internet Service Provider (ISP) <b>826</b>. ISP <b>826</b> in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” <b>828</b>. Local network <b>822</b> and Internet <b>828</b> both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link <b>820</b> and through communication interface <b>818</b>, which carry the digital data to and from computer system <b>800</b>, are exemplary forms of transporting the information.

p-0147Computer system <b>800</b> can send messages and receive data, including program code, through the network(s), network link <b>820</b> and communication interface <b>818</b>. In the Internet example, a server <b>830</b> might transmit a requested code for an application program through Internet <b>828</b>, ISP <b>826</b>, local network <b>822</b> and communication interface <b>818</b>. In accordance with the invention, one such downloaded application provides for the techniques described herein.

p-0148The received code may be executed by processor <b>804</b> as it is received, and/or stored in storage device <b>810</b>, or other non-volatile storage for later execution. In this manner, computer system <b>800</b> may obtain application code for the techniques described herein.

p-01495.0 Extensions and Alternatives

p-0150In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.