KR20050002628A - System and method for automatic negotiation of a security protocol - Google Patents

Abstract

PURPOSE: An automatic negotiation system and a method of a security protocol are provided to establish a safe connection between an internal node and an external node when a matching protocol is discovered between the first protocol set and the second protocol set, thereby enabling safe communication establishment and authentication with an external agent or the external node. CONSTITUTION: A processing is started(402), and a request for safe connection establishing is generated(404). The request is transmitted to a receiving node(406), and the receiving node receives the request(408). The receiving node compares the first protocol set with the second protocol set to decide whether protocols are matched(410). If so, the node decides whether more than one matching protocol is discovered(412). If so, the node selects one of the matched protocols(414), and starts a safe connection or session between an external agent and an internal manager(416). A specific protocol is exchanged between the agent and the manager(418). The agent and the manager authenticate nodes with each other(420). The safe connection or session is performed between the agent and the manager(422). If the safe session is completed, the safe connection is released(424), and the processing is terminated(426).

Description

SYSTEM AND METHOD FOR AUTOMATIC NEGOTIATION OF A SECURITY PROTOCOL}

TECHNICAL FIELD The present invention relates to network computing technology, and more particularly, to automatic negotiation of a security protocol between a security-enabled domain and one or more external nodes.

Advances in networking technology have enabled network administrators and others to more precisely maintain security controls for networks and other installations. Microsoft Windows NT 2000 and related products, for example, enable administrators to deploy security-enabled network domains using the Active Directory ™ (AD) architecture. Similarly, the known Kerberos network standard allows nodes in a network to authenticate each other using a key / authentication platform. By using this off-rating technique, network administrators can push rules, applications, patches, drives and other resources from network servers, for example, to a uniform installation to individual workstations or other clients in a secure manner. can do. All machines in the security-enabled domain described above can identify and authenticate the transmission of these and other types of data in a transparent manner.

However, passing rules, applications, or other resources to the workstation becomes much more difficult if the node is outside of the above security-enabled domain. For example, there may be several computers on a LAN within a company, while also interacting with computers in remote locations that do not belong to Active Directory ™ or other security-enabled domains. The establishment of a connection between a machine that is internal to the domain and a machine outside of that domain requires agreement on mutually supported security protocols, so communication at the boundary of the security domain becomes more complicated.

Therefore, a system administrator or the like must attempt to configure entry of an external agent or node into a security-enabled domain by identifying a compatible protocol between the internal and external machines before the session begins. do. For example, the external agent may be configured to communicate with a management server in the security-enabled domain described above using a transport layer security (TLS) protocol, a Kerberos-based protocol, a secure socket layer (SSL), or other protocol. Can be. The machine may further indicate a protocol failure within its protocol, i.e., the default protocol, and request switching of the protocol or other response to the external node or agent. Thus, manual setting or adjustment of security, transfer, and other protocols is required, and this process can be time consuming and error prone. In addition, other problems may exist.

1 is a diagram illustrating a network structure in which an embodiment of the present invention may operate.

2 illustrates a negotiation process between an internal node and an external node according to an embodiment of the present invention.

3 illustrates a comparison between protocol tables in accordance with an embodiment of the present invention.

4 illustrates overall protocol negotiation processing in accordance with an embodiment of the present invention.

<Explanation of symbols for the main parts of the drawings>

102: security-enabled domain

104: manager

106: Internal agent

108: certificate

110: certificate authority

112: the Internet

114: External agent

116: certificate

SUMMARY OF THE INVENTION The present invention solves the problems of the prior art described above, and according to one aspect provides a secure communication with an external agent or node that can be established and authenticated in an automated manner without requiring administrator intervention. An autonegotiation system and method of a security protocol are provided. In accordance with one aspect of the present invention, a network manager or other agent or node in a security-enabled domain may initiate an attempt to establish a secure connection with an external agent or node. The request includes a data field indicating the set of security protocols available to the manager. The external agent receives the request and compares the protocol available to the internal agent or manager with a set of protocols supported by the external agent. If a match is found between the available protocols, then communication proceeds based on the selected protocol. In this embodiment, each of the external agent and the internal agent can authenticate each other through a key, certificate, or other authentication mechanism.

<Example>

1 illustrates a network structure in which a protocol negotiation platform and method according to an embodiment of the present invention may be performed. As shown, in the illustrated embodiment, a set of clients, servers, agents, or other nodes or machines operate in a security-enabled domain 102. The security-enabled domain is, for example, Microsoft Windows ™ Active Directory ™, Kerberos or other certificate-based or key-based domain, or other closed or secure distributed directory or other environment in this embodiment, or These may be included. Within the security-enabled domain described above is an internal manager 104 for illustration, which is shown in this embodiment as a set of internal agents 106 (A1, A2, ..., AN). N may be any number) as well as a server or other node or include them.

The set of internal agents 106 in this embodiment operates within an additional server, workstation or other client, or the security-enabled domain 102 described above and with the internal manager 104 described above. It may consist of or include other internal agents or nodes that communicate. In this embodiment, the internal manager 104 schedules or performs network management functions such as forwarding or "pushing" network rules or other data for the set of internal agents 106, and the other data described above. The furnace may be storage (eg, RAID policy, failover criteria, memory limit), operational guidelines regarding bandwidth usage, or other rules or data. When communicating these or other types of data, the internal manager 104 and the set of internal agents 106 utilize the security resources of the security-enabled domain to ensure the integrity and integrity of the network. Ensure distribution of rules and other data.

In this embodiment, the security-enabled domain 102 may provide an authorization service using a certificate such as, for example, certificate 108, which certificate may be a certificate configured according to X.509 or other standard or format. Or it may include the same. Keys or other mechanisms may likewise be used. As shown, the certificate 108 may be associated with or provide authorization data for the internal manager 104. Any one of the above set of internal agents 106 permits a rule, command or other data received from the internal manager 104 by communicating the certificate 108 to the certificate authority 110 for verification. can do. Certificate authority 110 may itself be located inside security-enabled domain 102 or outside of security-enabled domain 102 described above.

In this embodiment, the certificate authority 110 is configured to read and decrypt the certificate 108 or other authorization mechanisms and return the results to the above set of internal agents 106 or other nodes. Or may include them. Each node in the set of internal agents 106 may likewise be associated with a certificate, key or other authorization data that is compatible with the security-enabled domain 102 described above. The nodes in the internal agent 106 described above may likewise communicate with each other using certificates or other mechanisms to permit each other.

In the embodiment shown in FIG. 1, the external agent 114 may likewise be configured to communicate with the internal manager 104 via the communication network 112. The external agent 114 may also be or include a server, workstation or other node or resource. In addition, the external agent 114 may likewise be associated with a certificate 116 that identifies the external agent 114 for authorization. In the present embodiment, as the communication network 112 in which the external agent 114 can communicate with the internal manager 104 or other internal nodes, for example, the Internet, intranet, LAN, WAN, MAN ( metropolitan area network (SAN), frame relay connection, Advanced Intelligent Network (AIN) connection, synchronous optical network (SONET) connection, digital T1, T3, E1, E3 line, DDS (Digital Data Service) connection, ATM connection, FDDI ( Fiber Distributed Data Interface (CDI), Copper Distributed Data Interface (CDI) or any other wired, wireless or optical connection, or may include or interface with them. The external agent 114 may be or include a workstation, server, wireless network-enabled device, or other node, agent, or platform configured for network communication in this embodiment.

Unlike conventional cross-domain communication implementations, according to the present invention, the external agent 114 initiates a contact with the internal manager 104 to exchange compatible protocols with each other in an automatic or transparent manner based on mutually compatible protocols. By selecting, a secure connection can be established. As illustrated in FIG. 2, the external application 130 running on the external agent 114 may initiate a contact with the internal manager through the external negotiation engine 126. The external application 130 may be or include a system utility, productivity, or other application such as a data backup scheduler, firewall, virus protection or other application. The external application 130 may require, for example, a user profile, update, or other data for performing the above-described communication with the internal manager 104 by performing various tasks.

The external negotiation engine 126 processes and manages the communication requested by the external application 130 to transfer the interoperable communication link for the internal manager 104 to the security-enabled domain 102. It can be established. In the present embodiment, as shown, the external negotiation engine 126 may initiate and manage the negotiation module 1180, which is an implementation of the known Simple and Protected GSS-API Negotiation (SPNEGO) protocol. Protocols may also be used In this embodiment, the negotiation module 118 described above may be accessed, initiated, or generated via an operating system of the external agent 114, for example, via an application program interface (API) or other mechanism. have.

The external negotiation engine 126 likewise uses an external transport specifier 120 to indicate other channels or message-based channels that may be employed by the external agent 114 to execute the protocol negotiation process. It can be included or generated. For example, in this embodiment, the external transport specifier 120 specifies the Security Support Provider Interface (SSPI) protocol as part of the Microsoft .NET architecture, such that the external application 130 or other software or modules may be, for example, a DLL. (dynamic link libraries) or other resources that support standard cryptographic or other encoding schemes. Other protocols may be used or specified within the external transport specifier 120. The external negotiation engine 126 consequently communicates a datagram indicating the data or other data to the internal negotiation engine 128 connected to the internal manager 104 as shown in FIG. can do.

The internal negotiation engine 128 may likewise include or interface the negotiation module 122 and the internal transport specifier 124. The internal negotiation engine 128 may also communicate with the internal application 132 executed in or accessed by the internal manager 104. For example, internal application 132 may be or include system management, productivity, or other application. When the internal negotiation engine 128 receives a communication establishment request with the internal manager 104, the internal transport designator 124 confirms channel communication using the SSPI protocol, for example. It is possible to establish a message-based or other channel with the external agent 114.

With a preliminary channel established between the external agent 114 and the internal manager 104, the external negotiation engine 126 and the external negotiation engine 128 are protocol negotiation and reduction. May be initiated. In this embodiment, the external agent 114 transmits the external protocol table 134 shown in FIG. 3 to the external manager 104. The external protocol table 134 may specify a protocol in which the external agent 114 is configured. When the internal manager 104 receives the external protocol table 134, the table 134 indicates an internal protocol table 136 representing a set of security protocols available to the internal manager 104. Is compared with Any one of the above-described external protocol table 134 and internal protocol table 136 may be, for example, transport layer security (TLS), secure socket layer (SSL), Kerberos, secure IP (IPSec) or the like. It contains fields that indicate the protocols or standards available. The negotiation engine 128 connected to the internal manager 104 identifies one or more protocols supported by the external agent 114 and the internal manager 104 as shown in FIG.

In this embodiment, the negotiation engine 128 likewise communicates the internal protocol table 136 to the negotiation engine 126 connected to the external agent 114 for protocol comparison. Negotiation engine 126 and negotiation engine 128 as a result negotiate a selection of protocols available to each other to establish secure communication in the security-enabled domain. For example, if only one common protocol is available for both the external agent 114 and the internal manager 104, then the external agent 114 and the internal manager 104 may use the corresponding protocol, such as TLS or other protocols. You will agree to set up the session using. If the negotiation engine 126 and the negotiation engine 128 agree that no common protocol will be found, then the attempt to establish cross-domain communication will end. Conversely, if the negotiation engine 126 and the negotiation engine 128 confirm that multiple protocols are common, network criteria or other factors such as transfer speed, bit depth of key or other security mechanisms, etc. You will select one protocol to use based on.

By placing compatible protocols, a secure session will be established between the external agent 114 and the internal manager 104. In this embodiment, in order to enhance security, the external agent 114 and the internal manager 104 each perform an authentication step similarly to verify the identity, privilege level, or other security details of the other node. will verify. As shown in FIG. 1, this may be done using a certificate or other security mechanism. The external agent 114 may authenticate the internal manager 104 by communicating the certificate 108 to the certificate authority 110. In contrast, the internal manager 104 may authenticate the external agent 114 by communicating the certificate 116 to the certificate authority 110. Other security mechanisms may be used.

In this embodiment, the type or content of data exchanged between the external agent 114 and the internal manager 104 will depend on mutual authentication between these two nodes. For example, access to network management rules or parameters may be reserved for internal nodes or external nodes and may only indicate the privilege level of a given access. Other certification rules or criteria may be used. After the operational security protocol is established and the authentication process is completed, the external agent 114 and the internal manager 104 exchange data, applications, rules or other information. Once the traffic is complete, the negotiation engine 126 and negotiation engine 128 release or terminate the communication link described above.

4 illustrates overall network negotiation processing in accordance with an embodiment of the present invention. Processing begins at step 402. In step 404, a request is made for establishing a secure connection in the security-enabled network 102 by the external agent 114, the internal manager 104, or other client, agent, or node. In step 406, the secure connection establishment request is sent to a receiving node, where the receiving node may be an internal manager 104, an external agent 114 or other client, agent or node, and the request Contains a first set of protocols that are compatible with the transmitting node. In step 408, the request is received at the receiving node. In step 410, a receiving node, which may be an internal manager 104, an external agent 114, or other client, agent or node, compares the first protocol set with a second protocol set of the receiving node. It determines whether there is a match among the available protocols.

If a match is found between the first protocol set and the second protocol set, the processing proceeds to step 412 to determine whether one or more matching protocols are found. If more than one matching protocol is found, processing proceeds to step 414 to select one of the matching protocols to use based on protocol criteria or other factors such as transmission speed, bit depth of key or other security mechanism. . Processing then proceeds to step 416 where a secure connection or session is initiated between the external agent 114 and the internal manager 104 based on the selected protocol. Similarly, even if only one matching protocol is found in step 412, processing proceeds to step 416 where a secure connection or session can be initiated. For example, the ports designated in this embodiment will be open under TCP / IP or other communications or other protocols described above.

In step 418, a protocol-specific exchange is initiated between the external agent 114 and the internal manager 104 by performing a handshake and other steps in accordance with the matching protocol described above. In step 420, either or both of the above-described external agent 114 and the internal manager 104 may have a corresponding certificate 116 (of the above-described external agent 114) or the above-described internal manager ( 104) The corresponding counterpart 108 can be properly sent to the certificate authority 110 to authenticate the corresponding counterpart node. In this embodiment, the certificate 116 or certificate 108 or other secure data described above may be or include a certificate object conforming to the X.509 standard or other standard or format. When proper authentication is completed, processing proceeds to step 422 to establish a secure connection or session between the external agent 114 and the internal manager 104. For example, a network or other rule may be communicated between these two nodes for system management or other purposes.

When the secure session is completed, processing proceeds to step 424 to terminate or release the secure connection between the external agent 114 and the internal manager 104. At step 426, processing may end or be repeated to return to a previous processing point or to perform another action. Similarly, if it is determined in step 410 that no matching protocol is identified, the process may proceed to step 426 to terminate or repeat processing, return to a previous processing point, or perform other actions.

The above description is for illustrative purposes only, and various modifications may be made to construction and implementation by those skilled in the art. For example, while the present invention has been described in connection with one external agent 114, the internal manager 104 or other client or node in the domain 102 where multiple external agents or nodes are secure-enabled. It may also be configured to automatically perform matching protocol negotiation with the. Similarly, although the mechanism described above is supported by one authentication entity 110 using X.509 or other standards, multiple authentication entities or other authentication or authorization platforms may be employed. . In addition, although only one hardware, software, or other resource is shown / described, they may be distributed, or similarly, the illustrated / described resources may be combined as being distributed.

In addition, although one or the other node or agent that is external to the security-enabled domain 102 and the node or agent that is internal to the domain have been described as initiating negotiation of the security protocol, the present invention has been described. Any node or agent configured according to may initiate protocol processing regardless of whether it is external or internal to the domain. Similarly, either or both of the internal and external agents may initiate authentication for the other agent or node. Therefore, it is to be understood that the scope of the present invention is limited only by the claims.

As described above, according to the automatic negotiation system and method of the security protocol of the present invention, it is possible to establish and authenticate secure communication with an external agent or a node in an automated manner without requiring administrator intervention.

Claims (62)

In the automatic negotiation (negotiate) method of the security protocol (security protocol), Receive a security authorization request to establish a secure connection between an internal node and an external node, wherein the internal node is internal to a security-enabled domain, and the external node is the security- Is external to an enabled domain; Comparing a first protocol set associated with the internal node with a second protocol set associated with the external node; And Establishing a secure connection between the internal node and the external node when a matching protocol is found between the first protocol set and the second protocol set. Security protocol auto-negotiation method comprising a. The method of claim 1, And wherein the external node comprises at least one of a computer and a network-enabled wireless device. The method of claim 1, And wherein the internal node comprises at least one of a client computer and a server. The method of claim 1, And wherein the security-enabled domain comprises a distributed directory domain. The method of claim 1, And wherein said security-enabled domain comprises a certificate-based domain. The method of claim 5, And wherein the certificate-based domain includes a Kerberos-enabled domain. The method of claim 6, And the matching protocol includes an X.509 certificate. The method of claim 1, And wherein the security permission request is generated by the external node. The method of claim 8, And receiving the security permission request is executed by the internal node. The method of claim 1, And the security permission request is generated by the internal node. The method of claim 10, Receiving the security permission request is executed by the external node. The method of claim 1, Terminating the secure connection when the session between the external node and the internal node is completed. The method of claim 1, And terminating connection processing if no match is found between the first protocol set and the second protocol set. The method of claim 1, Selecting a protocol to use for establishing the secure connection when a plurality of matching protocols are found. The method of claim 1, And authorizing at least one of the internal node and the external node. The method of claim 15, The authorization step includes the step of communicating the certificate to a certificate authority (certificate authority). In the automatic negotiation system of the security protocol (security protocol), A first interface to an internal protocol that is internal to the security-enabled domain and has an associated first protocol set; A second interface to an external protocol that is external to the security-enabled domain and has an associated second protocol set; And Receive a security authorization request to establish a secure connection between the internal node and the external node, and establish a first protocol set associated with the internal node and a second protocol set associated with the external node; In comparison, a negotiation engine that establishes a secure connection between the internal node and the external node when a matching protocol between the first protocol set and the second protocol set is found. Security protocol auto-negotiation system comprising a. The method of claim 17, And wherein the external node comprises at least one of a computer and a network-enabled wireless device. The method of claim 17, And the internal node comprises at least one of a client computer and a server. The method of claim 17, And wherein the security-enabled domain comprises a distributed directory domain. The method of claim 17, And wherein said security-enabled domain comprises a certificate-based domain. The method of claim 21, And wherein the certificate-based domain has a Kerberos-enabled domain. The method of claim 22, And the matching protocol comprises an X.509 certificate. The method of claim 17, And the security permission request is generated by the external node. The method of claim 24, And receiving the security permission request is executed by the internal node. The method of claim 17, And the security permission request is generated by the internal node. The method of claim 26, And receiving the security permission request is executed by the external node. The method of claim 17, And the negotiation engine terminates the secure connection when the session between the external node and the internal node is completed. The method of claim 17, And the negotiation engine terminates connection processing if no match is found between the first protocol set and the second protocol set. The method of claim 17, And the negotiation engine selects a protocol for use in establishing the secure connection when a plurality of matching protocols are found. The method of claim 17, And at least one of the internal node and the external node grants the other. The method of claim 31, wherein The authorization comprises communicating a certificate to a certificate authority. In the automatic negotiation system of the security protocol (security protocol), First interface means for interfacing to an internal protocol that is internal to the security-enabled domain and has an associated first protocol set; Second interface means for interfacing to an external protocol that is external to a security-enabled domain and has an associated second protocol set; And Receive a security authorization request to establish a secure connection between the internal node and the external node, and establish a first protocol set associated with the internal node and a second protocol set associated with the external node; In comparison, negotiation means for establishing a secure connection between the internal node and the external node when a matching protocol between the first protocol set and the second protocol set is found. Security protocol auto-negotiation system comprising a. The method of claim 33, wherein And wherein the external node comprises at least one of a computer and a network-enabled wireless device. The method of claim 33, wherein And the internal node comprises at least one of a client computer and a server. The method of claim 33, wherein And wherein the security-enabled domain comprises a distributed directory domain. The method of claim 36, And wherein said security-enabled domain comprises a certificate-based domain. The method of claim 37, And wherein said security-enabled domain comprises a certificate-based domain. The method of claim 38, And the matching protocol comprises an X.509 certificate. The method of claim 33, wherein And the security permission request is generated by the external node. The method of claim 40, And the security permission request is received by the internal node. The method of claim 33, wherein And the security permission request is generated by the internal node. The method of claim 42, wherein And the security permission request is received by the external node. The method of claim 33, wherein And the negotiation engine terminates the secure connection when the session between the external node and the internal node is completed. The method of claim 33, wherein And the negotiation engine terminates connection processing if no match is found between the first protocol set and the second protocol set. The method of claim 33, wherein And the negotiation engine selects a protocol for use in establishing the secure connection when a plurality of matching protocols are found. The method of claim 33, wherein And at least one of the internal node and the external node grants the other. The method of claim 47, The authorization comprises communicating a certificate to a certificate authority. A computer readable medium storing a program for executing an automatic negotiation method of a security protocol, The method, Receive a security authorization request to establish a secure connection between an internal node and an external node, wherein the internal node is internal to a security-enabled domain, and the external node is the security- Is external to an enabled domain; Comparing a first protocol set associated with the internal node with a second protocol set associated with the external node; And Establishing a secure connection between the internal node and the external node when a matching protocol is found between the first protocol set and the second protocol set. Computer-readable medium comprising a. The method of claim 49, And wherein the external node comprises at least one of a computer and a network-enabled wireless device. The method of claim 49, And said internal node comprises at least one of a client computer and a server. The method of claim 49, And the security-enabled domain comprises a distributed directory domain. The method of claim 49, And the security-enabled domain comprises a certificate-based domain. The method of claim 53, And wherein said certificate-based domain has a Kerberos-enabled domain. The method of claim 54, And the matching protocol comprises an X.509 certificate. The method of claim 49, And the security authorization request is generated by the external node. The method of claim 56, wherein Receiving the security authorization request is executed by the internal node. The method of claim 49, And the security authorization request is generated by the internal node. The method of claim 58, Receiving the security authorization request is executed by the external node. The method of claim 49, And terminating the secure connection when the session between the external node and the internal node is completed. The method of claim 43, And terminating connection processing if no match is found between the first protocol set and the second protocol set. The method of claim 43, And terminating connection processing if no match is found between the first protocol set and the second protocol set.