TECHNICAL FIELD
[0001] The present disclosure generally relates to computers and computer-related technology.
More specifically, the present disclosure relates to systems and methods for credentials
distribution.
[0002] The use of electronic devices has become increasingly prevalent in modern society.
As the cost of electronic devices has declined, and as the usefulness of electronic
devices has increased, people are using them for a wide variety of purposes. For example,
many people use electronic devices to perform work tasks as well as to seek entertainment.
One type of an electronic device is a computer.
[0003] Computer technologies continue to advance at a rapid pace. Computers commonly used
include everything from hand-held computing devices to large multi-processor computer
systems. These computers include software, such as applications including user interfaces,
in order to make them useful and accessible to an end user. Computers are increasingly
linked with other computers through networks. With the expansion of computer technology,
the size of networks has continued to increase. As the size of networks has increased,
the use of computers configured as management nodes (i.e., computers configured to
manage other computers on the network) has increased. Networks may link computers
together that are a great distance apart.
[0004] One of the challenges involved with networks is security. To perform management tasks
on computing devices in a network, credentials may need to be entered. These credentials
may include a username and password. Management tasks may be implemented by a management
node using stored encrypted credentials. However, in some cases, a management node
may not have credentials needed to perform a task. As can be observed from this discussion,
systems and methods that provide secure peer-to-peer credential sharing, replication
and recovery may be beneficial.
[0005] US2015/358158 describes an arrangement in which each client device in the network has a private
key and a public key. For two client devices to securely exchange information, each
computes a shared secret based on its own private key and the other's public key.
The client devices use the shared secret to generate a shared secret key pair. The
shared secret public key is used as a key by each client device to store data in a
public key-value data store to share with the other client device. The shared data
is signed using the shared secret key pair. The shared data may also be encrypted
using the shared secret key pair. Each client device uses the shared secret public
key to retrieve the data from the public key-value data store. Each client device
uses the shared secret key pair to verify and decrypt the shared data.
[0006] US 2010/161965 pertains to a credential store that provides for secure storage of credentials. A
credential stored in the credential store is encrypted with the public key of a user
owning the credential. A first user may provide a credential owned by the first user
to a second user. The first user may add credentials owned by the first user to the
credential store. An administrator may manage users of the credential store without
having the ability to provide credentials to those users.
SUMMARY OF THE INVENTION
[0007] In a first aspect of the invention there is provided a method by a management server,
the method in accordance with claim 1.
[0008] In a second aspect of the invention there is provided a method by a responding management
node, the method in accordance with claim 11.
[0009] In another aspect of the invention there is provided a management server according
to claim 15.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010]
Figure 1 is a block diagram illustrating one configuration of a network for credentials
distribution;
Figure 2 is a flow diagram illustrating one configuration of a method for credentials
distribution;
Figure 3 is a flow diagram illustrating a configuration of a method for credentials
distribution implemented by a requesting management node;
Figure 4 is a flow diagram illustrating a configuration of a method for credentials
distribution implemented by a management server;
Figure 5 is a flow diagram illustrating a configuration of a method for credentials
distribution implemented by a responding management node;
Figure 6 is a sequence diagram illustrating an implementation of credentials distribution
according to the systems and methods described herein;
Figure 7 is a block diagram that illustrates one configuration of a network where
systems and methods for credentials distribution may be implemented; and
Figure 8 illustrates various components that may be utilized in a computing device.
DETAILED DESCRIPTION
[0011] A method by a management server is described. The method includes receiving a credentials
request from a requesting management node. The credentials request includes a public
key of the requesting management node. The method also includes determining whether
the management server has encrypted credentials for the requesting management node
in a local cache. The encrypted credentials are encrypted using the public key of
the requesting management node and cannot be decrypted by the management server. The
method further includes sending the encrypted credentials to the requesting management
node when the management server has the encrypted credentials. The requesting management
node can decrypt the encrypted credentials using a private key.
[0012] The requesting management node may send the credentials request upon determining
that credentials required to perform a task cannot be resolved or acquired. The requesting
management node may send the credentials request as part of an automated recovery
process that does not require a user to re-enter credentials.
[0013] When the management server determines that it does not have the encrypted credentials,
the method may further include sending a multicast request to one or more peer management
nodes. The multicast request may include the public key of the requesting management
node. The method may also include receiving a unicast response from a responding management
node that includes encrypted credentials for the requesting management node. The method
may further include sending the encrypted credentials received from the responding
management node to the requesting management node.
[0014] The method may also include storing the encrypted credentials received from the responding
management node in the local cache of the management server. The management server
may be a cloud-based server. The requesting management node and the one or more peer
management nodes may be part of a same tenancy.
[0015] When the credentials are initially set, the management server may use a public key
infrastructure (PKI) to encrypt the credentials in a manner in which only a management
node for which the credentials are encrypted can decrypt the credentials.
[0016] A management server is also described. The management server includes a processor,
memory in electronic communication with the processor and instructions stored in the
memory. The instructions are executable to receive a credentials request from a requesting
management node. The credentials request includes a public key of the requesting management
node. The instructions are also executable to determine whether the management server
has encrypted credentials for the requesting management node in a local cache. The
encrypted credentials are encrypted using the public key of the requesting management
node and cannot be decrypted by the management server. The instructions are further
executable to send the encrypted credentials to the requesting management node when
the management server has the encrypted credentials. The requesting management node
can decrypt the encrypted credentials using a private key.
[0017] A method by a responding management node is also described. The method includes receiving
a multicast request from a management server in response to a credentials request
sent by a requesting management node when the requesting management node determines
that credentials required to perform a task cannot be resolved or acquired. The multicast
request includes a public key of the requesting management node. The method also includes
resolving the credentials from a local store. The method further includes encrypting
the credentials using the public key of the requesting management node. The method
additionally includes sending a unicast response to the management server that includes
the encrypted credentials for the requesting management node.
[0018] The method may also include decrypting the credentials from the local store using
a private key of the responding management node if the credentials are encrypted before
re-encrypting the credentials using the public key of the requesting management node.
[0019] The method may also include testing a certificate of the requesting management node
with a certificate chain of the responding management node. The method may further
include validating that the requesting management node is trusted to receive credentials.
[0020] Various configurations of the systems and methods are now described with reference
to the Figures, where like reference numbers may indicate identical or functionally
similar elements. The configurations of the present systems and methods, as generally
described and illustrated in the Figures herein, could be arranged and designed in
a wide variety of different configurations. Thus, the following more detailed description
of several configurations, as represented in the Figures, is not intended to limit
the scope of the systems and methods, as claimed, but is merely representative of
the various configurations of the systems and methods.
[0021] Figure 1 is a block diagram illustrating one configuration of a network 100 for credentials
114 distribution. The network 100 may include a plurality of electronic devices that
are in electronic communication with one another.
[0022] The network 100 may include one or more Local Area Networks (LANs), Wide Area Networks
(WANs), Wireless Local Area Networks (WLANs), the Internet, etc. The network 100 may
include a plurality of management nodes 102 and at least one management server 104.
[0023] The management server 104 may be a cloud-based server. For example, the management
server 104 may be accessible via an Internet connection. The management server 104
may also be located physically at the same location as one or more of the management
nodes 102.
[0024] The network 100 also includes one or more management nodes 102. Examples of the management
node 102 include a desktop computer, laptop computer, tablet computer, smartphone,
router, printers, etc. A network segment (e.g., subnet) may include one or more management
nodes 102.
[0025] The management server 104 may perform a variety of management-related operations
in conjunction with the management node(s) 102. Examples of these management-related
operations include managing the managed node's 102 operating configurations, the managed
node's 102 files, etc.
[0026] In an implementation, management-related operations may be performed by an agent
operating on the management node 102. The agent may be part of a network management
system that is used to manage the management node 102. For example, management systems
may include one or more of the following software products: LANDesk Shavlik®, LANDesk
Wavelink Avalanche®, Altiris®, Microsoft® SCCM or a BMC® management system.
[0027] The management server 104 may coordinate management-related operations for one or
more tenants. As used herein, a "tenant" may be an organization, an enterprise, a
business, a customer, a university, a non-profit organization, a government agency,
etc. A single management server 104 may perform management-related operations for
multiple distinct tenants. For example, each of the tenants may share a single backend
cloud service for managing computers.
[0028] Each tenant may have one or more management nodes 102. In an implementation, a management
node 102 may include an agent or piece of installation software. A management node
102 may reside on a tenant's network 100. Each network 100 may have more than one
management node 102. For example, in a segmented network 100, there may be a management
node 102 in each network segment. A network segment may be a completely firewalled-off
subnet communicating with other subnets that are all completely firewalled. These
subnets may be located anywhere in the world.
[0029] The management nodes 102 may maintain a connection to the management server 104.
An end user (e.g., administrator) at the management server 104 may send computer management
instructions and may see results based on this connection.
[0030] The management server 104 may provide global management of multiple networks 100.
Each management node 102 in a given tenancy may be enrolled in a public key infrastructure
(PKI) that shares trust across the tenant. In a chain of trust, a public key 110 and
private key 108 pair form a certificate. The certificate of a management node 102
may be issued from a trusted certificate authority. The certificate may be specific
to a given tenant. A certificate of one management node 102 may sign the certificate
of another management node 102 in that tenant. In this way, a chain of trust may be
established between devices within a tenant. If for any reason, another tenant's certificate
would be passed to a management node 102, that management node 102 could detect that
the certificate was not trusted, because the certificate does not follow the chain
up to the initial trust that a management node 102 expects.
[0031] Each management node 102 may be configured with a set of tasks that it performs to
manage their respective network segments. Some tasks may require credentials 114.
The credentials 114 may include a user name and password. A management node 102 may
use the credentials 114 to access other nodes on the network 100 to perform a given
task. Examples of these tasks include, but are not limited to, making changes to the
operating system of a node, turning on and off firewalls and patching a node on the
network 100.
[0032] For administrative operations, the credentials 114 may be important ones (e.g., Administrator,
or Domain Administrator). For example, the management node 102 may log into a node
as the administrator using the administrator username and password. Because these
credentials 114 provide significant access to the network 100, it is important to
protect these credentials 114.
[0033] A user (e.g., network administrator) may wish to re-use components of their configuration
including confidential elements such as credentials 114 (e.g., usernames and passwords).
For example, if a management node 102 is installed and does not have the credentials
114 needed to perform a task, it may be beneficial to distribute the credentials 114
to that management node 102.
[0034] In one approach, this problem has been solved by installing agents on each endpoint
being managed, or installing a separate management server with no affiliation in each
network segment. The separate management servers may store a master copy of secrets
that can be retrieved as necessary. However, this results in multiple management servers
and increased system complexity.
[0035] In another approach, the secrets (i.e., credentials 114) are encrypted such that
they are stored in the cloud, but the decryption keys (e.g., private key 108) are
also in the cloud. In other words, a single management server may store encrypted
credentials 114 and the private key 108 to decrypt the credentials 114. However, if
a malicious user gains access to this data-store, this user very likely has the keys
required to access all the encrypted secrets.
[0036] In yet another approach, a user may have to enter missing credentials 114 every time
they are needed. However, this approach may be time consuming and frustrating for
a user. Therefore, when multiple management nodes 102 are installed in a network 100,
a user may wish to enter the credentials 114 a single time and have the credentials
114 securely distributed between the management nodes 102.
[0037] The systems and methods described herein provide for secure distribution, replication
and recovery of credentials 114. In the case of a cloud service, it is desirable for
the cloud service to not be responsible for maintaining the confidentiality of a tenant's
credentials 114. For example, if the cloud service is attacked, the cloud service
provider does not want to be responsible for keeping a tenant's secrets.
[0038] The described systems and methods allow a tenant to distribute credentials 114 from
the management server 104 or from a peer management node 102b in a secure manner.
The described systems and methods allow a management node 102 to access credentials
114 when the credentials 114 are not stored in a manner that is decryptable by the
management server 104.
[0039] As described above, each management node 102 has a configured set of tasks it performs
to manage their respective network segments. Some tasks require credentials 114. In
an implementation, the management server 104 (e.g., a cloud service) may be used to
configure these tasks. During this configuration, a user may set their credentials
114 for the given tasks into a web user interface (UI) 116 of the management server
104. In another implementation, a user may enter the credentials 114 directly into
a management node 102.
[0040] The management server 104 may use a PKI to encrypt all credentials 114 at the time
they are set in the web UI 116 in a manner where only the single management node 102
for which the credentials 114 are encrypted may decrypt the credentials 114. In order
to be most secure, credentials 114 are encrypted upon user input with a public/private
key pair that is established during registration of the management node 102. The credentials
114 are encrypted before they are persisted (e.g., stored) in the cloud in a manner
in which only the private key 108 holder can decrypt the secret. The private keys
108 are never available in the cloud, only on the installed endpoints (i.e., management
nodes 102).
[0041] When a user installs and configures a management node 102, the user may set up a
comprehensive policy for distributing credentials 114. The user may then install a
second management node 102 and reuse the credentials by reference without requiring
the user to re-enter the confidential passwords.
[0042] In an implementation, the management server 104 may have a store of public keys 110
for the various management nodes 102 in the network 100. The management server 104
may use the public key 110 of a given management node 102 to encrypt the credentials
114 for that management node 102. The management server 104 may then provide the encrypted
credentials 114 to the management node 102. The management node 102 may then decrypt
the credentials 114 using its private key 108.
[0043] The credentials 114 are never stored on the management server 104 in a form by which
the management server 104 itself may decrypt them. For example, the management server
104 may not store the private keys 108 of the management nodes 102. In one implementation,
once the user enters the credentials 114 into the web UI 116, the management server
104 may store the encrypted credentials 114a in a credentials cache 106c. However,
the management server 104 cannot decrypt these encrypted credentials 114a. In another
implementation, the management server 104 may encrypt the credentials 114 and send
the credentials to the management node 102 without saving the encrypted credentials
114a.
[0044] It should be noted that credentials cache 106c of the management server 104 may be
different than the credentials cache 106a of the requesting management node 102a.
For example, the credentials cache 106c of the management server 104 may include only
credentials 114a encrypted for specific management nodes 102. Therefore, the encrypted
credentials 114a in the credentials cache 106c are not decryptable by the management
server 104. By contrast, the credentials cache 106a on a management node 102 may contain
credentials 114 that are decryptable by the management node.
[0045] In some cases, a requesting management node 102a may determine that credentials 114
required to perform a task cannot be resolved or acquired. For example, the requesting
management node 102a may be newly installed on the network 100. This requesting management
node 102a may not have needed credentials 114 stored in its credentials cache 106a
to perform a given task.
[0046] In an implementation, when the requesting management node 102a starts up, it may
send a credential ID request to the management server 104. The management server 104
may have a credentials list 118 that includes the credential IDs 120 for one or more
credentials 114 that the requesting management node 102a should have to perform its
tasks. A credential ID 120 may be a random number that is assigned with given credentials
114. The management server 104 may send the credential IDs 120 to the requesting management
node 102a. Using these credential IDs 120, the requesting management node 102a may
check its local credentials cache 106a to see if it has these credentials 114 encrypted
specifically for that managed node 102a.
[0047] If the requesting management node 102a determines that it does not have the credentials
114, the requesting management node 102a may send a credentials request 112 to the
management server 104. The credentials request 112 may ask the management server 104
to provide the missing credentials 114. The requesting management node 102a may include
its public key 110a in the credentials request 112.
[0048] Upon receiving the credentials request 112 from the requesting management node 102a,
the management server 104 may determine whether it has encrypted credentials 114a
for the requesting management node 102a in a local cache. For example, the management
server 104 may check its credentials cache 106c to see whether it has stored the credentials
114a encrypted using the public key 110a of the requesting management node 102a. As
described above, the encrypted credentials 114a in the credentials cache 106c cannot
be decrypted by the management server 104.
[0049] If the management server 104 has the encrypted credentials 114a for the requesting
management node 102a, then the management server 104 may send the encrypted credentials
114a to the requesting management node 102a in a credentials response 124. Upon receiving
the credentials response 124, the requesting management node 102a may decrypt the
encrypted credentials 114a using its private key 108a. The requesting management node
102a may then use the credentials 114a to perform the configured task.
[0050] If the management server 104 does not have the encrypted credentials 114a for the
requesting management node 102a, then the management server 104 may send a multicast
request 126 to one or more peer management nodes 102b. These peer management nodes
102b may be in the same tenant as the requesting management node 102a. The management
server 104 may include a list of tenant peers 122 that identifies management nodes
102 within the same tenant. The management server 104 may send the multicast request
126 to one or more of the peer management nodes 102b that are included in the list
of tenant peers 122.
[0051] The multicast request 126 may identify which credentials 114 are requested. The multicast
request 126 may also include the public key 110a from the requesting management node
102a.
[0052] Upon receiving the multicast request 126, a peer management node 102b may respond
to the multicast request 126. This responding peer management node 102b (referred
to as a responding management node 102b) may validate that the credentials request
112 came from a requesting management node 102a that trusts the same certificate chain.
[0053] If the requesting management node 102a trusts the same certificate chain, then, upon
validation, the responding management node 102b may attempt to resolve the credentials
114 from its local store (i.e., credentials cache 106b) that had previously been set.
In this case, the responding management node 102b may store encrypted credentials
114b for itself. These encrypted credentials 114b may be encrypted with the public
key 110b of the responding management node 102b.
[0054] It should be noted that on a peer management node 102b, the credentials 114b may
be encrypted, but they are encrypted in a different manner than on the management
server 104. In this case, the encrypted credentials 114b stored on the peer management
node 102b are decryptable by the peer management node 102b, whereas the encrypted
credentials 114a stored on the management server 104 are not decryptable by the management
server 104.
[0055] Furthermore, the credentials 114b on a peer management node 102b may not be encrypted
at all. In other words, the peer management node 102b may store credentials 106b in
the credentials cache 106b in an unencrypted state.
[0056] If the responding management node 102b stores encrypted credentials 114b, then the
responding management node 102b may decrypt the encrypted credentials 114b using its
private key 108b. The responding management node 102b may then re-encrypt the credential
114b using the public key 110a of the requesting management node 102a that was included
in the multicast request 126. Unless the responding management node 102b decrypts
and shares the previously encrypted credentials 114b, there is no feasible approach
other than re-entry by the user to encrypt the credentials 114 for the newly registered
requesting management node 102a.
[0057] The responding management node 102b may then send a unicast response 130 to the management
server 104. The unicast response 130 may include the credentials 114 that are encrypted
for the requesting management node 102a. The management server 104 may (optionally)
store these encrypted credentials 114 in its credentials cache 106c. The management
server 104 may then send the encrypted credentials 114 to the requesting management
node 102a in a credentials response 124.
[0058] Upon receiving the credentials response 124, the requesting management node 102a
may decrypt the credentials 114 using its private key 108a. The requesting management
node 102a may then store the credentials locally for immediate or future use.
[0059] In an implementation, the described systems and methods may enable secure distribution,
replication of confidential information. This replication may be used for disaster
recovery scenarios. For example, in a multi-management node 102 network 100, one or
more management nodes 102 may be lost, destroyed or corrupted.
[0060] In re-installation of a lost endpoint (i.e., a lost management node 102), registration
to the same tenancy allows automated recovery of confidential information from peer
sources. For example, a user may reinstall a management node 102 on the network 100.
The reinstalled management node 102 may then register with the management server 104
to acquire any credentials 114 as described above. The end user does not need to do
any additional data entry to recover these credentials 114.
[0061] The described systems and methods enable global management and re-use of confidential
information such as passwords without ever allowing the credentials 114 to be persisted
in the cloud (e.g., the management server 104) in a manner in which the confidential
information may be decrypted.
[0062] Figure 2 is a flow diagram illustrating one configuration of a method 200 for credentials
114 distribution. The method 200 may be implemented by a management server 104. The
management server 104 may be in communication with one or more management nodes 102
via a network 100.
[0063] The management server 104 may receive 202 a credentials request 112 from a requesting
management node 102a. The credentials request 112 may include a public key 110a of
the requesting management node 102a. For example, the requesting management node 102a
may send the credentials request 112 to the management server 104 upon determining
that the credentials 114 required to perform a task cannot be resolved or acquired.
[0064] The management server 104 may determine 204 whether it has credentials 114 encrypted
for the requesting management node 102a in a local cache. The credentials 114 may
be encrypted using the public key 110a of the requesting management node 102a and
cannot be decrypted by the management server 104.
[0065] The management server 104 may send 206 the encrypted credentials 114 to the requesting
management node 102a when the management server 104 has the encrypted credentials
114. If the management server 104 determines 204 that it has encrypted credentials
114 for the requesting management node 102a in a credentials cache 106c, the management
server 104 may send 206 the encrypted credentials 114 to the requesting management
node 102a.
[0066] If the management server 104 determines 204 that it does not have encrypted credentials
114 for the requesting management node 102a, then the management server 104 may send
a multicast request 126 to one or more peer management nodes 102b. The multicast request
126 may include the public key 110a of the requesting management node 102a.
[0067] Upon receiving the multicast request 126, a responding management node 102b may validate
that the requesting management node 102a is trusted to receive credentials. This may
be done by testing the certificate of the requesting management node 102a with its
certificate chain.
[0068] Upon validation, the responding management node 102b may resolve the credentials
114 from its local store (e.g., credentials cache 106b) and may decrypt the credentials
114 using its private key 108b. The responding management node 102b may then re-encrypt
the credentials 114 using the public key 110a of the requesting management node 102a.
The responding management node 102b may send the encrypted credentials 114 in a unicast
response 130 to the management server 104.
[0069] Upon receiving the unicast response 130, the management server 104 may send 206 the
encrypted credentials 114 received from the responding management node 102b to the
requesting management node 102a in a credentials response 124. The requesting management
node 102a can decrypt the encrypted credentials 114 using its private key 108a.
[0070] Figure 3 is a flow diagram illustrating a configuration of a method 300 for credentials
114 distribution implemented by a requesting management node 102a. The requesting
management node 102a may be in communication with a management server 104 via a network
100 that includes one or more peer management nodes 102b.
[0071] The requesting management node 102a may send 302 a credential ID request to the management
server 104. The management server 104 may have a credentials list 118 that includes
the credential IDs 120 for one or more credentials 114 that the requesting management
node 102a should have to perform its tasks.
[0072] The requesting management node 102a may receive 304 one or more credential IDs 120
from the management server 104. For example, upon receiving the credential ID request,
the management server 104 may send the one or more credential IDs 120 to the requesting
management node 102a.
[0073] The requesting management node 102a may determine 306 that credentials 114 required
to perform a task cannot be resolved or acquired. For example, the requesting management
node 102a may check its credentials cache 106a using the one or more credential IDs
120. The requesting management node 102a may determine that it does not have one or
more credentials 114 indicated by the credential IDs 120.
[0074] The requesting management node 102a may send 308 a credentials request 112 to the
management server 104. The credentials request 112 may include the public key 110a
of the requesting management node 102a. The credentials request 112 may identify the
one or more credentials 114 that the requesting management node 102a is missing.
[0075] The requesting management node 102a may receive 310 a credentials response 124 from
the management server 104 that includes the requested credentials 114 encrypted using
the public key 110a. For example, upon receiving the credentials request 112, the
management server 104 may determine whether encrypted credentials 114 for the requesting
management node 102a are in its credentials cache 106c. The encrypted credentials
114 may be encrypted using the public key 110a of the requesting management node 102a
and cannot be decrypted by the management server 104.
[0076] In one case, if the management server 104 has the encrypted credentials 114a already
encrypted with the public key 110a of the requesting management node 102a stored in
its credentials cache 106c, the management server 104 may send the encrypted credentials
114a to the requesting management node 102a in a credentials response 124. In another
case, if the management server 104 determines that it does not have encrypted credentials
114a for the requesting management node 102a, then the management server 104 may send
a multicast request 126 to one or more peer management nodes 102b. The multicast request
126 may include the public key 110a of the requesting management node 102a.
[0077] A responding management node 102b may resolve the credentials 114 from its local
store, decrypt the credentials 114 using its private key 108b, and then re-encrypt
the credentials 114 using the public key 110a of the requesting management node 102a.
The requesting management node 102a may then send the encrypted credentials 114 in
a unicast response 130 to the management server 104. Upon receiving the unicast response
130, the management server 104 may send the encrypted credentials 114 received from
the responding management node 102b to the requesting management node 102a in a credentials
response 124.
[0078] The requesting management node 102a may decrypt 312 the encrypted credentials 114
using its private key 108a. Because the credentials 114 were encrypted using the public
key 110a of the requesting management node 102a, the requesting management node 102a
may decrypt 312 the credentials 114 received in the credentials response 124. The
requesting management node 102a may immediately use the decrypted credentials 114.
The requesting management node 102a may store the credentials 114 in its credentials
cache 106a for future use.
[0079] Figure 4 is a flow diagram illustrating a configuration of a method 400 for credentials
114 distribution implemented by a management server 104. The management server 104
may be in communication with one or more management nodes 102 via a network 100.
[0080] The management server 104 may receive 402 a credentials request 112 from a requesting
management node 102a. The credentials request 112 may include a public key 110a of
the requesting management node 102a.
[0081] The management server 104 may determine 404 whether credentials 114 encrypted for
the requesting management node 102a are in a credentials cache 106c. The credentials
114 may be encrypted using the public key 110a of the requesting management node 102a
and cannot be decrypted by the management server 104. If the management server 104
has the encrypted credentials 114a stored in the credentials cache 106c, the management
server 104 may send 406 the encrypted credentials 114a to the requesting management
node 102a.
[0082] If the management server 104 determines 404 that it does not have encrypted credentials
114 for the requesting management node 102a, then the management server 104 may send
408 a multicast request 126 to one or more peer management nodes 102b. The multicast
request 126 may include the public key 110a of the requesting management node 102a.
The requesting management node 102a and the one or more peer management nodes 102b
may be part of the same tenancy.
[0083] The management server 104 may receive 410 a unicast response 130 from a responding
management node 102b. The unicast response 130 may include encrypted credentials 114
for the requesting management node 102a. For example, the responding management node
102b may resolve the credentials 114 from its local store, decrypt the credentials
114 using its private key 108b, and then re-encrypt the credentials 114 using the
public key 110a of the requesting management node 102a. The responding management
node 102b may then send the encrypted credentials 114 in a unicast response 130 to
the management server 104.
[0084] Upon receiving the unicast response 130, the management server 104 may send 412 the
encrypted credentials 114 received from the responding management node 102b to the
requesting management node 102a. The management server 104 may send 412 the credentials
114 in a credentials response 124. The requesting management node 102a can decrypt
the encrypted credentials 114 using its private key 108a.
[0085] Figure 5 is a flow diagram illustrating a configuration of a method 500 for credentials
114 distribution implemented by a responding management node 102b. The responding
management node 102b may be in communication with a management server 104 via a network
100 that includes a requesting management node 102a.
[0086] The responding management node 102b may receive 502 a multicast request 126 from
the management server 104. The multicast request 126 may include the public key 110a
of the requesting management node 102a. For example, the requesting management node
102a may send a credentials request 112 to the management server 104 that includes
the public key 110a. If the management server 104 does not have the credentials 114a
encrypted with the public key 110a stored in its credentials cache 106c, the management
server 104 may send the multicast request 126 to one or more peer management nodes
102b in the network 100.
[0087] Upon receiving the multicast request 126, the responding management node 102b may
validate 504 that the requesting management node 102a trusts the same certificate
chain. For example, the responding management node 102b may determine that it and
the requesting management node 102a belong to the same tenant.
[0088] Upon validation, the responding management node 102b may resolve 506 the credentials
114 from its local store (e.g., credentials cache 106b). If the credentials 114 are
encrypted, the responding management node 102b may decrypt 508 the credentials 114
using its private key 108b. The responding management node 102b may then encrypt 510
the credentials 114 using the public key 110a of the requesting management node 102a.
[0089] The responding management node 102b may send 512 a unicast response 130 to the management
server 104. The unicast response 130 may include the encrypted credentials 114 for
the requesting management node 102a. The management server 104 may then forward the
encrypted credentials 114 to the requesting management node 102a in a credentials
response 124.
[0090] Figure 6 is a sequence diagram illustrating an implementation of credentials 114
distribution according to the systems and methods described herein. A network 100
may include a requesting management node 602a, a responding management node 602b and
a management server 604.
[0091] The requesting management node 602a may determine 601 that it needs to acquire credentials
114 to perform a task. For example, the requesting management node 602a may need the
credentials 114 to perform an administrative task on a node within its network segment.
The requesting management node 602a may make this determination based on one or more
credential IDs 120 provided by the management server 604.
[0092] The requesting management node 602a may send 603 a credentials request 112 to the
management server 604. The management server 604 may check 605 its local cache (e.g.,
credentials cache 106c) for the requested credentials 114. The credentials 114 may
be encrypted using the public key 110a of the requesting management node 602a and
cannot be decrypted by the management server 604.
[0093] In a first case (Case 1), the management server 604 has the encrypted credentials
114a stored in its local cache. In this case, the management server 604 may send 607
a credentials response 124 that includes the encrypted credentials 114a to the requesting
management node 602a.
[0094] In a second case (Case 2), the management server 604 does not have the encrypted
credentials 114a stored in its local cache. In this case, the management server 604
may send 609 a multicast request 126 to one or more peer management nodes 102b (including
the responding management node 602b). The peer management nodes 102b may be included
in the same tenancy as the requesting management node 602a. The multicast request
126 may include the public key 110a of the requesting management node 602a.
[0095] Upon receiving the multicast request 126, the responding management node 602b may
validate that the requesting management node 602a is trusted to receive credentials.
This may be done by testing the certificate of the requesting management node 602a
with its certificate chain.
[0096] Upon validation, the responding management node 602b may resolve 611 the credentials
114 from its local store (e.g., credentials cache 106b). The responding management
node 602b may decrypt 613 the credentials 114 using its private key 108b. The responding
management node 602b may then re-encrypt 615 the credentials 114 using the public
key 110a of the requesting management node 602a.
[0097] The responding management node 602b may send 617 a unicast response 130 to the management
server 604. The unicast response 130 may include the encrypted credentials 114 for
the requesting management node 602a.
[0098] The management server 604 may (optionally) store 619 the encrypted credentials 114
in its credentials cache 106c. The management server 604 may then send 621 the encrypted
credentials 114 to the requesting management node 602a in a credentials response 124.
The requesting management node 602a may decrypt 623 the encrypted credentials 114
using its private key 108a.
[0099] Figure 7 is a block diagram that illustrates one configuration of a network 700 where
systems and methods for credentials 114 distribution may be implemented. A management
server 704 is connected to a router 744. The router 744 is connected to switches 746a,
746b, and 746c. The switch 746a is connected to several nodes 750a, 750b, 750c, etc.,
via their respective subnets 748a, 748b, and 748c. The switch 746b is connected to
several nodes 750d, 750e, 750f, etc., via their respective subnets 748d, 748e, and
748f. The switch 746c is connected to several nodes 750g, 750h, and 750i, etc., via
their respective subnets 748g, 748h and 748i. Subnet I 748i includes one or more management
nodes 702.
[0100] Although Figure 7 only shows one router 744, and a limited number of switches 746,
subnets 748 and nodes 750, many and varied numbers of routers 744, switches 746, subnets
748 and nodes 750 may be included in networks and/or systems that may implement systems
and methods for credentials 114 distribution.
[0101] It should be noted that the management server 704 may be implemented in accordance
with the management server 104 described in connection with Figure 1. Furthermore,
the management nodes 702 may be examples of one or more of the requesting management
node 102a and peer management nodes 102b described herein.
[0102] Figure 8 illustrates various components that may be utilized in a computing device
852. The computing device 852 may be configured in accordance with one or more of
the requesting management nodes 102a, 602a, the peer management node 102b and the
management servers 104, 604, 704 and the responding management node 602b described
herein.
[0103] The computing device 852 may include a processor 803 and memory 805. The memory 805
may include instructions 807a and data 809a. The processor 803 controls the operation
of the computing device 852 and may be, for example, a microprocessor, a microcontroller,
a digital signal processor (DSP) or other device known in the art. The processor 803
typically performs logical and arithmetic operations based on program instructions
807b and/or data 809b received from the memory 805.
[0104] The computing device 852 typically may include one or more communication interfaces
811 for communicating with other electronic devices. The communication interfaces
811 may be based on wired communication technology, wireless communication technology
or both. Examples of different types of communication interfaces 811 include a serial
port, a parallel port, a Universal Serial Bus (USB), an Ethernet adapter, an IEEE
bus interface, a small computer system interface (SCSI) bus interface, an infrared
(IR) communication port, a Bluetooth wireless communication adapter and so forth.
[0105] The computing device 852 typically may include one or more input devices 813 and
one or more output devices 815. Examples of different kinds of input devices 813 include
a keyboard, mouse, microphone, remote control device, button, joystick, trackball,
touchpad, lightpen, etc. Examples of different kinds of output devices 815 include
a speaker, printer, etc. One specific type of output device that may be included in
a computer system is a display device 817. Display devices 817 used with configurations
disclosed herein may utilize any suitable image projection technology, such as liquid
crystal display (LCD), light-emitting diode (LED), gas plasma, electroluminescence,
a cathode ray tube (CRT) or the like.
[0106] A display controller 819 may also be provided, for converting data stored in the
memory 805 into text, graphics and/or moving images (as appropriate) shown on the
display device 817. Of course, Figure 8 illustrates only one possible configuration
of a computing device 852. Various other architectures and components may be utilized.
[0107] In the above description, reference numbers have sometimes been used in connection
with various terms. Where a term is used in connection with a reference number, this
is meant to refer to a specific element that is shown in one or more of the Figures.
Where a term is used without a reference number, this is meant to refer generally
to the term without limitation to any particular Figure.
[0108] The term "determining" encompasses a wide variety of actions and, therefore, "determining"
can include calculating, computing, processing, deriving, investigating, looking up
(e.g., looking up in a table, a database or another data structure), ascertaining
and the like. Also, "determining" can include receiving (e.g., receiving information),
accessing (e.g., accessing data in a memory) and the like. Also, "determining" can
include resolving, selecting, choosing, establishing and the like.
[0109] The phrase "based on" does not mean "based only on," unless expressly specified otherwise.
In other words, the phrase "based on" describes both "based only on" and "based at
least on."
[0110] The term "processor" should be interpreted broadly to encompass a general purpose
processor, a central processing unit (CPU), a microprocessor, a digital signal processor
(DSP), a controller, a microcontroller, a state machine and so forth. Under some circumstances,
a "processor" may refer to an application specific integrated circuit (ASIC), a programmable
logic device (PLD), a field programmable gate array (FPGA), etc. The term "processor"
may refer to a combination of processing devices, e.g., a combination of a DSP and
a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction
with a DSP core or any other such configuration.
[0111] The term "memory" should be interpreted broadly to encompass any electronic component
capable of storing electronic information. The term memory may refer to various types
of processor-readable media such as random access memory (RAM), read-only memory (ROM),
non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable
programmable read only memory (EPROM), electrically erasable PROM (EEPROM), flash
memory, magnetic or optical data storage, registers, etc. Memory is said to be in
electronic communication with a processor if the processor can read information from
and/or write information to the memory. Memory that is integral to a processor is
in electronic communication with the processor.
[0112] The terms "instructions" and "code" should be interpreted broadly to include any
type of computer-readable statement(s). For example, the terms "instructions" and
"code" may refer to one or more programs, routines, sub-routines, functions, procedures,
etc. "Instructions" and "code" may comprise a single computer-readable statement or
many computer-readable statements.
[0113] The term "computer-readable medium" refers to any available non-transitory tangible
medium that can be accessed by a computer or processor. By way of example, and not
limitation, a computer-readable medium may comprise RAM, ROM, EEPROM, CD-ROM or other
optical disk storage, magnetic disk storage or other magnetic storage devices or any
other medium that can be used to carry or store desired program code in the form of
instructions or data structures and that can be accessed by a computer. Disk and disc,
as used herein, include compact disc (CD), laser disc, optical disc, digital versatile
disc (DVD), floppy disk and Blu-ray® disc where disks usually reproduce data magnetically,
while discs reproduce data optically with lasers.
[0114] Software or instructions may also be transmitted over a transmission medium. For
example, if the software is transmitted from a website, server or other remote source
using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL)
or wireless technologies such as infrared, radio, and microwave, then the coaxial
cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared,
radio and microwave are included in the definition of transmission medium.
[0115] The methods disclosed herein comprise one or more steps or actions for achieving
the described methods. The method steps and/or actions may be interchanged with one
another without departing from the scope of the claims. In other words, unless a specific
order of steps or actions is required for proper operation of the method that is being
described, the order and/or use of specific steps and/or actions may be modified without
departing from the scope of the claims.
[0116] It is to be understood that the claims are not limited to the precise configuration
and components illustrated above. Various modifications, changes and variations may
be made in the arrangement, operation and details of the systems, methods and apparatus
described herein without departing from the scope of the claims.
1. A method by a management server (104, 704), comprising:
receiving (112, 304, 402) a credentials request from a requesting management node
(102a, 602a, 702) from a plurality of management nodes on a network (100), wherein
the credentials request includes a public key (110a) of the requesting management
node;
determining whether the management server (104, 704) has encrypted credentials encrypted
(114a) for the requesting management node in a credentials cache (106c), wherein the
encrypted credentials are encrypted using the public key (110a) of the requesting
management node (102a, 602a) and cannot be decrypted by the management server (104,
704);
sending (124, 206, 406) the encrypted credentials to the requesting management node
when the management server (104, 704) has the encrypted credentials, wherein the requesting
management node (102a, 602a), after receiving (310) the encrypted credentials, can
decrypt (312) the encrypted credentials using a private key (108a) of the requesting
management node (102a); and
when the management server (104, 704) does not have (204) the encrypted credentials:
sending (126, 408) a multicast request to one or more peer management nodes (102b)
from the plurality of management nodes on the network (100), the multicast request
including the public key (110a) of the requesting management node (102a);
receiving (130, 410) a unicast response from a responding management node from the
one or more peer management nodes(102b), the unicast response including the encrypted
credentials (114b) encrypted for the requesting management node; and
sending (412) the encrypted credentials received from the responding management node
to the requesting management node.
2. The method of claim 1, wherein the credentials cache (106a, 106b) includes only encrypted
credentials that are encrypted for specific management nodes form the plurality of
management nodes.
3. The method of claim 1, wherein the requesting management node (602a) sends the credentials
request upon determining (601) that credentials required to perform a task cannot
be resolved or acquired.
4. The method of claim 1, wherein, upon receiving (410) the multicast request, the responding
management node (102b) resolves (611) the credentials from a credentials cache (106b)
of the responding management node and encrypts (615) the credentials using the public
key (110b) of the requesting management node.
5. The method of claim 1, wherein, upon receiving (410) the multicast request, the responding
management node decrypts (613) encrypted credentials encrypted for the responding
management node using a private key (108b) of the responding management node to obtain
the credentials and re-encrypts the credentials using the public key of the requesting
management node.
6. The method of claim 1, wherein the responding management node, before sending (617)
the unicast response, validates that the requesting management node is trusted to
receive the credentials by testing a certificate of the requesting management node
with a certificate chain of the responding management node.
7. The method of claim 1, further comprising:
storing the encrypted credentials received from the responding management node in
the credentials cache of the management server.
8. The method of claim 1, wherein the requesting management node and the one or more
peer management nodes are part of a same tenancy.
9. The method of claim 1, further comprising, when the credentials are initially set,
using a public key infrastructure (PKI) to encrypt the credentials in a manner in
which only a management node for which the credentials are encrypted can decrypt the
credentials.
10. The method of claim 1, wherein the credentials are required by the requesting management
node (102a) to perform (601) one or more tasks, the management server further comprising
a credentials list including one or more credential IDs for the credentials, the method
further comprising: upon receiving a credential ID request from the requesting management
node, sending the one or more credential IDs to the requesting management node such
that the requesting management node, in response to receiving the one or more credential
IDs, can determine using the one or more credential IDs whether the requesting management
node has the credentials and, when the requesting management node determines that
the requesting management node does not have the credentials, send the credentials
request to the management server.
11. A method by a responding management node (602b), comprising:
receiving (609) a multicast request from a management server (104, 604) in response
to a credentials request (603) sent by a requesting management node (102a, 602a) to
the management server, wherein the multicast request includes a public key of the
requesting management node;
resolving (611) credentials from a credentials cache of the responding management
node;
encrypting (615) the credentials for the requesting management node using the public
key of the requesting management node; and
sending (617) a unicast response to the management server (104, 604) that includes
the credentials encrypted for the requesting management node.
12. The method of claim 11, further comprising decrypting (613), if the credentials are
encrypted for the responding management node (104, 604), the credentials encrypted
for the responding management node and stored in the credentials cache using a private
key of the responding management node before re-encrypting the credentials using the
public key of the requesting management node.
13. The method of claim 11, further comprising:
testing a certificate of the requesting management node with a certificate chain of
the responding management node; and
validating by the testing that the requesting management node is trusted to receive
the credentials before sending the unicast response.
14. The method of claim 11, wherein the requesting management node and the responding
management node are part of a same tenancy.
15. A management server (104, 604), comprising:
a processor (803);
memory (805) in electronic communication with the processor (803); and
instructions (807a) stored in the memory (805), the instructions being executable
to perform the methods of any of claims 1 to 10.
1. Verfahren durchgeführt von einem Management-Server (104, 704), umfassend:
Empfangen (112, 304, 402) einer Berechtigungsnachweis-Abfrage von einem abfragenden
Managementknoten (102a, 602a, 702) aus einer Vielzahl von Managementknoten eines Netzwerks
(100), wobei die Berechtigungsnachweis-Abfrage einen Public Key (110a) des abfragenden
Managementknotens enthält;
Feststellen, ob der Management-Server (104, 704) verschlüsselte Berechtigungsnachweise
aufweist, welche für den abfragenden Managementknoten verschlüsselt (114a) in einem
verschlüsselten Cache (106c) liegen, wobei die verschlüsselten Berechtigungsnachweise
unter Verwendung des Public Key (110a) des abfragenden Managementknotens (102a, 602a)
verschlüsselt sind und vom Management-Server (104, 704) nicht entschlüsselt werden
können;
Senden (124, 206, 406) der verschlüsselten Berechtigungsnachweise an den abfragenden
Managementknoten, wenn der Management-Server (104, 704) über die verschlüsselten Berechtigungsnachweise
verfügt, wobei der abfragende Managementknoten (102a, 602a), nach Empfang (310) der
verschlüsselten Berechtigungsnachweise, die verschlüsselten Berechtigungsnachweise
unter Verwendung von einem Private Key (108a) des abfragenden Managementknotens (102a)
entschlüsseln (312) kann; und
wenn der Management-Server (104, 408) den verschlüsselten Berechtigungsnachweis nicht
aufweist (204):
Senden (126, 408) einer Multicast-Abfrage an einen oder mehrere Peer Managementknoten
(102b) aus der Vielzahl von Managementknoten des Netzwerks (100), wobei die Multicast-Abfrage
den Public Key (110a) des abfragenden Managementknoten (102a) enthält;
Empfangen (130, 410) einer Unicast Rückmeldung von einem antwortenden Managementknoten
aus dem einen oder den mehreren Peer Managementknoten (102b), wobei die Unicast Rückmeldung,
welche die verschlüsselten Berechtigungsnachweise, welche für den abfragenden Managementknoten
verschlüsselt sind, enthält; und
Senden (412) der verschlüsselten Berechtigungsnachweise, welche von dem antwortenden
Managementknoten empfangen wurden, an den abfragenden Managementknoten.
2. Verfahren nach Anspruch 1, wobei der verschlüsselte Cache (106a, 106b)lediglich verschlüsselte
Berechtigungsnachweise enthält, welche für spezifische Managementknoten, welche die
Vielzahl der Managementknoten bilden, verschlüsselt sind.
3. Verfahren nach Anspruch 1, wobei der abfragende Managementknoten (602a) die Berechtigungsnachweis-Abfrage,
nach dem Feststellen (601), ob Berechtigungsnachweise, welche erforderlich sind, um
einen Task auszuführen, nicht geklärt oder vorgenommen werden können, sendet.
4. Verfahren nach Anspruch 1, wobei, nach dem Empfangen (410) der Multicast-Abfrage,
der antwortende Managementknoten (102b) die Berechtigungsnachweise aus einem Berechtigungsnachweise-Cache
(106b) des antwortenden Managementknotens vornimmt (611) und die Berechtigungsnachweise
unter Verwendung des Public Key (110b) des abfragenden Managementknotens verschlüsselt
(615).
5. Verfahren nach Anspruch 1, wobei, nach dem Empfangen (410) der Multicast-Abfrage,
der antwortende Managementknoten verschlüsselte Berechtigungen, welche für den antwortenden
Managementknoten, unter Verwendung eines Private Key (108b) des antwortenden Managementknotens,
verschlüsselt sind, entschlüsselt (613), um die Berechtigungsnachweise zu erhalten,
und die Berechtigungsnachweise, unter Verwendung des Public Key des abfragenden Managementknotens,
wiederverschlüsselt.
6. Verfahren nach Anspruch 1, wobei der antwortende Managementknoten, vor dem Senden
(617) der Unicast-Antwort, bestätigt, dass dem abfragenden Managementknoten vertraut
werden kann, um die Berechtigungsnachweise zu empfangen, indem ein Zertifikat des
abfragenden Managementknotens mit einer Zertifikat-Kette des antwortenden Managementknotens
getestet wird.
7. Verfahren nach Anspruch 1, ferner umfassend:
Speichern der verschlüsselten Berechtigungsnachweise, welche von dem antwortenden
Managementknoten in dem Berechtigungsnachweise Cache des Management-Servers empfangen
wurden.
8. Verfahren nach Anspruch 1, wobei der abfragende Managementknoten und der eine oder
die mehreren Peer-Managementknoten Teil von derselben Tenancy sind.
9. Verfahren nach Anspruch 1, ferner umfassend, wenn die Berechtigungsnachweise erstmalig
festgelegt werden, das Verwenden einer Public-Key-Infrastruktur (PKI), um die Berechtigungsnachweise
so zu verschlüsseln, dass lediglich ein Managementknoten, für den die Berechtigungsnachweise
verschlüsselt sind, die Berechtigungsnachweise entschlüsseln kann.
10. Verfahren nach Anspruch 1, wobei die Berechtigungsnachweise von dem anfragenden Managementknoten
(102a) angefordert werden, um einen oder mehrere Tasks auszuführen (601), wobei der
Management-Server ferner eine Berechtigungsnachweise-Liste umfasst, welche eine oder
mehrere Berechtigungsnachweis-IDs für die Berechtigungsnachweise enthält, wobei dieses
Verfahren ferner umfasst:
nach Empfang einer Berechtigungsnachweis-ID-Abfrage von dem abfragenden Managementknoten,
das Senden der einen oder mehreren Berechtigungsnachweis-IDs an den abfragenden Managementknoten,
so dass der abfragende Managementknoten, in Beantwortung auf das Empfangen der einen
oder mehreren IDs, unter Verwendung der einen oder mehreren Berechtigungsnachweis-IDs
feststellen kann, ob der abfragende Managementknoten die Berechtigungsnachweise besitzt
und, wenn der abfragende Managementknoten bestimmt, dass der abfragende Managementknoten
die Berechtigungsnachweise nicht besitzt, die Berechtigungsnachweis-Abfrage an den
Management-Server sendet.
11. Verfahren durchgeführt von einem antwortenden Managementknoten (602b), umfassend:
Empfangen (609) einer Multicast-Abfrage von einem Management-Server (104, 604) in
Beantwortung einer Berechtigungsnachweis-Abfrage (603), welche von einem abfragenden
Managementknoten (102a, 602a) an den Management-Server gesendet wurde, wobei die Multicast-Abfrage
einen Public Key des abfragenden Managementknoten enthält;
Klären (611) von Berechtigungsnachweisen von einem Berechtigungsnachweise-Cache des
antwortenden Managementknotens;
Verschlüsseln (615) der Berechtigungsnachweise für den abfragenden Managementknoten
unter Verwendung des Public Key des abfragenden Managementknoten; und
Senden (617) einer Unicast-Antwort an den Management-Server (104, 604), welcher die
Berechtigungsnachweise, welche für den abfragenden Managementknoten verschlüsselt
sind, aufweist.
12. Verfahren nach Anspruch 11, ferner umfassend das Entschlüsseln (613), wenn die Berechtigungsnachweise
für den antwortenden Managementknoten (104, 604) verschlüsselt sind, der Berechtigungsnachweise,
welche für den antwortenden Managementknoten verschlüsselt sind und in dem Berechtigungsnachweise-Cache
gespeichert sind, unter Verwendung eines Privat Key des antwortenden Managementknotens,
vor dem Wieder-Verschlüsseln der Berechtigungsnachweise unter Verwendung des Public-Key
des abfragenden Managementknoten.
13. Verfahren nach Anspruch 11, ferner umfassend:
Prüfen eines Zertifikates des abfragenden Managementknoten mit einer Zertifikat-Kette
des antwortenden Managementknoten; und
Bestätigen, mittels dem Prüfen, dass der abfragende Managementknoten vertrauenswürdig
ist, um die Berechtigungsnachweise vor dem Senden der Unicast- Antwort zu empfangen.
14. Verfahren nach Anspruch 11, wobei der abfragende Managementknoten und der antwortende
Managementknoten Teil derselben Tenancy sind.
15. Management-Server (104, 604) umfassend:
einen Prozessor (803);
Speicher (805) in elektronischer Kommunikation mit dem Prozessor (803); und
Anweisungen (807a), welche in dem Speicher (805) gespeichert sind, wobei die Anweisungen
umsetzbar sind, um die Verfahren nach irgendeinem der Ansprüche 1 bis 10 durchzuführen.
1. Procédé mis en œuvre par le biais d'un serveur de gestion (104, 704), comprenant :
la réception (112, 304, 402) d'une requête d'informations d'identification en provenance
d'un nœud sollicitant de gestion (102a, 602a, 702) à partir d'une pluralité de nœuds
de gestion dans un réseau (100), selon lequel la requête d'informations d'identification
comporte une clé publique (110a) du nœud sollicitant de gestion ;
le calcul de savoir si le serveur de gestion (104, 704) présente des informations
d'identification qui ont été chiffrées (114a) pour le nœud sollicitant de gestion
dans une cache à informations d'identification (106c), selon lequel les informations
d'identification chiffrées sont chiffrées par le biais de la clé publique (110a) du
nœud sollicitant de gestion (102a, 602a) et ne peuvent être déchiffrées par le serveur
de gestion (104, 704) ;
l'envoi (124, 206, 406) des informations d'identification chiffrées au nœud sollicitant
de gestion lorsque le serveur de gestion (104, 704) possède les informations d'identification
chiffrées, selon lequel le nœud sollicitant de gestion (102a, 602a), après réception
(310) des informations d'identification chiffrées, peut déchiffrer (312) les informations
d'identification chiffrées par le biais d'une clé privée (108a) du nœud sollicitant
de gestion (102a) ; et
lorsque le serveur de gestion (104, 704) ne possède pas (204) les informations d'identification
chiffrées :
l'envoi (126, 408) d'une requête à diffusion multiple à un ou plusieurs nœuds paires
de gestion (102b) en provenance de la pluralité de nœuds de gestion dans le réseau
(100), la requête à diffusion multiple comportant le clé publique (110a) du nœud sollicitant
de gestion (102a) ;
la réception (130, 410) d'une réponse à diffusion unique en provenance d'un nœud répondant
de gestion à partir d'un ou de plusieurs des nœuds paires de gestion (102b), la réponse
à diffusion unique comportant les informations d'identification chiffrées (114b) qui
ont été chiffrées pour le nœud sollicitant de gestion ; et
l'envoi (412) des informations d'identification chiffrées reçues en provenance du
nœud répondant de gestion au nœud sollicitant de gestion.
2. Procédé selon la revendication 1, selon lequel la cache d'informations d'identification
(106a, 106b) ne comporte que des informations d'identification chiffrées qui ont été
chiffrées pour des nœuds de gestion spécifiques parmi la pluralité de nœuds de gestion.
3. Procédé selon la revendication 1, selon lequel le nœud sollicitant de gestion (602a)
envoie la requête d'informations d'identification après un calcul (601) que les informations
d'identification nécessaires pour effectuer une opération ne peuvent être résolues
ou acquises.
4. Procédé selon la revendication 1, selon lequel, lors de la réception (410) de la requête
à diffusion multiple, le nœud répondant de gestion (102b) résout (611) les informations
d'identification à partir d'une cache d'informations d'identification (1065) du nœud
répondant de gestion et chiffre (615) les informations d'identification par le biais
de la clé publique (110b) du nœud sollicitant de gestion.
5. Procédé selon la revendication 1, selon lequel, lors de la réception (410) de la requête
à diffusion multiple, le nœud répondant de gestion déchiffre (613) les informations
d'identification chiffrées qui ont été chiffrées pour le nœud répondant de gestion
par le biais d'une clé privée (108b) du nœud répondant de gestion afin d'obtenir les
informations d'identification et chiffre à nouveau les informations d'identification
par le biais de la clé publique du nœud sollicitant de gestion.
6. Procédé selon la revendication 1, selon lequel le nœud répondant de gestion, avant
l'envoi (617) de la réponse à diffusion unique, valide qu'on peut faire confiance
au nœud sollicitant de gestion pour recevoir les informations d'identification, en
testant un certificat du nœud sollicitant de gestion avec une chaîne de certificats
du nœud répondant de gestion.
7. Procédé selon la revendication 1, comprenant en outre :
le stockage des informations d'identification chiffrées reçues en provenance du nœud
répondant de gestion dans la cache d'informations d'identification du serveur de gestion.
8. Procédé selon la revendication 1, selon lequel le nœud sollicitant de gestion et le
ou les plusieurs nœuds paires de gestion font partie d'une même occupation.
9. Procédé selon la revendication 1, comprenant en outre, lors du réglage initial des
informations d'identification, l'utilisation d'une infrastructure à clé publique (PKI)
afin de chiffrer les informations d'identification de sorte que seul un nœud de gestion
pour lequel les informations d'identification ont été chiffrées est capable de déchiffrer
les informations d'identification.
10. Procédé selon la revendication 1, selon lequel les informations d'identification sont
requises par le nœud sollicitant de gestion (102a) afin d'effectuer (601) une ou plusieurs
opérations, le serveur de gestion comprenant en outre une liste d'informations d'identification
comportant un ou plusieurs identifiants d'information d'identification pour les informations
d'identification, le procédé comprenant en outre :
lors de la réception d'une requête d'identifiant d'information d'identification en
provenance du nœud sollicitant de gestion, l'envoi du ou des plusieurs identifiants
d'information d'identification au nœud sollicitant de gestion de sorte que le nœud
sollicitant de gestion, en réponse à la réception du ou des plusieurs identifiants
d'information d'identification, est capable de calculer si, en utilisant le ou les
plusieurs identifiants d'information d'identification, le nœud sollicitant de gestion
possède les informations d'identification et, lorsque le nœud sollicitant de gestion
détermine que le nœud sollicitant de gestion ne possède pas les informations d'identification,
l'envoi de la requête d'informations d'identification au serveur de gestion.
11. Procédé mis en œuvre par un nœud répondant de gestion (602b), comprenant :
la réception (609) d'une requête à diffusion multiple en provenance d'un serveur de
gestion (104, 604) en réponse à une requête d'informations d'identification (603)
envoyée par un nœud sollicitant de gestion (102a, 602a) au serveur de gestion, selon
lequel la requête à diffusion multiple comporte une clé publique du nœud sollicitant
de gestion ;
la résolution (611) d'informations d'identification à partir d'une cache d'informations
d'identification du nœud répondant de gestion ;
le chiffrage (615) des informations d'identification pour le nœud sollicitant de gestion
par le biais de la clé publique du nœud sollicitant de gestion ; et
l'envoi (617) d'une réponse à diffusion unique au serveur de gestion (104, 604) qui
comporte les informations d'identification chiffrées pour le nœud sollicitant de gestion.
12. Procédé selon la revendication 11, comprenant en outre le déchiffrage (613), si les
informations d'identification sont chiffrées pour le nœud sollicitant de gestion (104,
604), des informations d'identification qui ont été chiffrées pour le nœud répondant
de gestion et stockées dans la cache d'informations d'identification par le biais
d'une clé privée du nœud répondant de gestion avant de chiffrer à nouveau les informations
d'identification par le biais de la clé publique du nœud sollicitant de gestion.
13. Procédé selon la revendication 11, comprenant en outre :
le test d'un certificat du nœud sollicitant de gestion avec une chaîne de certificats
du nœud répondant de gestion ; et
la validation du fait du test qu'une confiance peut être accordée au nœud sollicitant
de gestion pour recevoir les informations d'identification avant l'envoi de la réponse
à diffusion unique.
14. Procédé selon la revendication 11, selon lequel le nœud sollicitant de gestion et
le nœud répondant de gestion font partie d'une même occupation.
15. Serveur de gestion (104, 604), comprenant :
un processeur (803) ;
une mémoire (805) en communication électronique avec le processeur (803) ; et
des instructions (807a) stockées dans la mémoire (805), les instructions pouvant être
exécutées afin de mettre en œuvre les procédés selon l'une quelconque des revendications
1 à 10.