rfc9642v4.txt | rfc9642.txt | |||
---|---|---|---|---|
skipping to change at line 1683 ¶ | skipping to change at line 1683 ¶ | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
</certificates> | </certificates> | |||
</asymmetric-key> | </asymmetric-key> | |||
</asymmetric-keys> | </asymmetric-keys> | |||
</keystore> | </keystore> | |||
4. Encrypting Keys in Configuration | 4. Encrypting Keys in Configuration | |||
This section describes an approach that enables both the symmetric | This section describes an approach that enables both the symmetric | |||
and asymmetric keys on a server to be encrypted, such that | and asymmetric keys on a server to be encrypted, such that backup/ | |||
traditional backup/restore procedures can be used without concern for | restore procedures can be used without concern for raw key data being | |||
raw key data being compromised when in transit. | compromised when in transit. | |||
The approach presented in this section is not normative. This | The approach presented in this section is not normative. This | |||
section answers how a configuration containing secrets that are | section answers how a configuration containing secrets that are | |||
encrypted by a built-in key (Section 3) can be backed up from one | encrypted by a built-in key (Section 3) can be backed up from one | |||
server and restored on a different server when each server has unique | server and restored on a different server when each server has unique | |||
master keys. The API defined by the "ietf-keystore" YANG module | primary keys. The API defined by the "ietf-keystore" YANG module | |||
presented in this document is sufficient to support the workflow | presented in this document is sufficient to support the workflow | |||
described in this section. | described in this section. | |||
4.1. Key Encryption Key | 4.1. Key Encryption Key | |||
The ability to encrypt configured keys is predicated on the existence | The ability to encrypt configured keys is predicated on the existence | |||
of a key encryption key (KEK). There may be any number of KEKs in a | of a key encryption key (KEK). There may be any number of KEKs in a | |||
server. A KEK, by its namesake, is a key that is used to encrypt | server. A KEK, by its namesake, is a key that is used to encrypt | |||
other keys. A KEK MAY be either a symmetric key or an asymmetric | other keys. A KEK MAY be either a symmetric key or an asymmetric | |||
key. | key. | |||
skipping to change at line 1762 ¶ | skipping to change at line 1762 ¶ | |||
longer be operational. | longer be operational. | |||
In other deployments, an organization's crypto officer, possessing a | In other deployments, an organization's crypto officer, possessing a | |||
KEK's cleartext value, configures the same KEK on the second server, | KEK's cleartext value, configures the same KEK on the second server, | |||
presumably as a hidden key or a key protected by access control, so | presumably as a hidden key or a key protected by access control, so | |||
that the cleartext value is not disclosed to regular administrators. | that the cleartext value is not disclosed to regular administrators. | |||
However, this approach creates high coupling to and dependency on the | However, this approach creates high coupling to and dependency on the | |||
crypto officers that does not scale in production environments. | crypto officers that does not scale in production environments. | |||
In order to decouple the crypto officers from the regular | In order to decouple the crypto officers from the regular | |||
administrators, a special KEK, called the "master key" (MK), may be | administrators, a special KEK, called the "primary key" (PK), may be | |||
used. | used. | |||
An MK is commonly a globally unique built-in (see Section 3) | A PK is commonly a globally unique built-in (see Section 3) | |||
asymmetric key. The private raw key value, due to its long lifetime, | asymmetric key. The private raw key value, due to its long lifetime, | |||
is hidden (i.e., "hidden-private-key"; see Section 2.1.4.5. of | is hidden (i.e., "hidden-private-key"; see Section 2.1.4.5. of | |||
[RFC9640]). The raw public key value is often contained in an | [RFC9640]). The raw public key value is often contained in an | |||
identity certificate (e.g., IDevID). How to configure an MK during | identity certificate (e.g., IDevID). How to configure an PK during | |||
the manufacturing process is outside the scope of this document. | the manufacturing process is outside the scope of this document. | |||
Assuming the server has an MK, the MK can be used to encrypt a | Assuming the server has a PK, the PK can be used to encrypt a "shared | |||
"shared KEK", which is then used to encrypt the keys configured by | KEK", which is then used to encrypt the keys configured by regular | |||
regular administrators. | administrators. | |||
With this extra level of indirection, it is possible for a crypto | With this extra level of indirection, it is possible for a crypto | |||
officer to encrypt the same KEK for a multiplicity of servers offline | officer to encrypt the same KEK for a multiplicity of servers offline | |||
using the public key contained in their identity certificates. The | using the public key contained in their identity certificates. The | |||
crypto officer can then safely hand off the encrypted KEKs to regular | crypto officer can then safely hand off the encrypted KEKs to regular | |||
administrators responsible for server installations, including | administrators responsible for server installations, including | |||
migrations. | migrations. | |||
In order to migrate the configuration from a first server, an | In order to migrate the configuration from a first server, an | |||
administrator would need to make just a single modification to the | administrator would need to make just a single modification to the | |||
skipping to change at line 1798 ¶ | skipping to change at line 1798 ¶ | |||
configuration (containing many encrypted keys) can be loaded into the | configuration (containing many encrypted keys) can be loaded into the | |||
second server while enabling the second server to decrypt all the | second server while enabling the second server to decrypt all the | |||
encrypted keys in the configuration. | encrypted keys in the configuration. | |||
The following diagram illustrates this idea: | The following diagram illustrates this idea: | |||
+-------------+ +-------------+ | +-------------+ +-------------+ | |||
| shared KEK | | shared KEK | | | shared KEK | | shared KEK | | |||
|(unencrypted)|-------------------------------> | (encrypted) | | |(unencrypted)|-------------------------------> | (encrypted) | | |||
+-------------+ encrypts offline using +-------------+ | +-------------+ encrypts offline using +-------------+ | |||
^ each server's MK | | ^ each server's PK | | |||
| | | | | | |||
| | | | | | |||
| possesses \o | | | possesses \o | | |||
+-------------- |\ | | +-------------- |\ | | |||
/ \ shares with | | / \ shares with | | |||
crypto +--------------------+ | crypto +--------------------+ | |||
officer | | officer | | |||
| | | | |||
| | | | |||
+----------------------+ | +----------------------+ | +----------------------+ | +----------------------+ | |||
| server-1 | | | server-2 | | | server-1 | | | server-2 | | |||
| configuration | | | configuration | | | configuration | | | configuration | | |||
| | | | | | | | | | | | |||
| | | | | | | | | | | | |||
| +----------------+ | | | +----------------+ | | | +----------------+ | | | +----------------+ | | |||
| | MK-1 | | | | | MK-2 | | | | | PK-1 | | | | | PK-2 | | | |||
| | (hidden) | | | | | (hidden) | | | | | (hidden) | | | | | (hidden) | | | |||
| +----------------+ | | | +----------------+ | | | +----------------+ | | | +----------------+ | | |||
| ^ | | | ^ | | | ^ | | | ^ | | |||
| | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | |||
| | encrypted | | | | encrypted | | | | encrypted | | | | encrypted | | |||
| | by | | | | by | | | | by | | | | by | | |||
| | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | |||
| +----------------+ | | | +----------------+ | | | +----------------+ | | | +----------------+ | | |||
End of changes. 8 change blocks. | ||||
12 lines changed or deleted | 12 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |