Disk encryption key escrow in IPA

Data in LDAP

Escrow packet storage

Stored in ipaUniqueID=..., cn=volume_keys, dc=.... The following information is stored per each packet:

Attribute	Meaning and use	Comment
Packet ID	ipaUniqueID used in the DN	dm-crypt volumes do not carry any identifier for distinguishing even between two volumes on a host
Escrow packet	A blob containing the encrypted "secret"	Size probably 1000–1500 bytes
Host reference	Host this packet applies to
"Secret" type	Purpose of the packet: data encryption key / passphrase / other
Volume identification	Multi-valued: properties of the volume that can be used to identify the correct packet
Packet filing time	Time when this packet was sent to the server	Provided by the directory server automatically in creationTimestamp
Obsoletion time	If this packet stores an obsolete secret, time when the server was notified about it	Used for automatic deletion of old secrets

Details:

attributeType ( TBD
       NAME 'ipaVolumeEscrowPacket' 
       DESC 'An encrypted packet containing a secret used for encrypting the volume'
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.5   # Binary
       SINGLE-VALUE
       X-ORIGIN 'IPA v2' )

attributeType ( TBD
       NAME 'ipaVolumeHost'
       DESC 'Link to the host that contains this volume' SUP memberHost
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12   # DN
       X-ORIGIN 'IPA v2' )

attributeType ( TBD
       NAME 'ipaVolumeKeySecretType' 
       DESC 'Type of the secret defined in this packet'
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15   # DirectoryString
       SINGLE-VALUE
       X-ORIGIN 'IPA v2' )

Defined values: "data encryption key" and "passphrase", more can be added in the future. This corresponds to LIBVK_SECRET_* in libvolume_key.h.

attributeType ( TBD
       NAME 'ipaVolumeInfo' 
       DESC 'Information about a volume: NAME:VALUE'
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.40   # OctetString
       X-ORIGIN 'IPA v2' )

A multi-valued attribute, stores information about the volume that allows the user to select which escrow packet to use. Each value is a NAME:VALUE string, with NAME consisting of characters in [a-zA-z0-9_/]. The expected values include the LIBVKP_VP_IDENTIFICATION properties of the volume reported by libvk_volume_dump_properties, e.g.

Name	Value
hostname	Host name, as known on the computer
volume_format	Volume format, corresponds to LIBVK_VOLUME_FORMAT_* in libvolume_key.h
volume_uuid	Volume UUID, using a volume format-specific syntax
volume_label	Volume label
volume_path	Path to a block special file representing the device on the specified host. The path is not necessarily "canonical". There might be more than one attribute value with this NAME.
luks/passphrase_slot	An integer identifying the LUKS slot a passphrase is valid for

attributeType ( TBD
       NAME 'ipaVolumeKeyObsoletionTimestamp' 
       DESC 'Time when a key was marked as obsolete'
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.24   # GeneralizedTime
       SINGLE-VALUE
       X-ORIGIN 'IPA v2' )

objectClass ( TBD
      NAME 'ipaVolumeKey' 
      SUP top STRUCTURAL
      MUST ( ipaUniqueID $ ipaVolumeHost $ ipaVolumeEscrowPacket )
      MAY ( ipaVolumeKeySecretType $ ipaVolumeInfo $ ipaVolumeKeyObsoletionTimestamp ) 
      X-ORIGIN 'IPAv2>' )

Suggested indices:

• An equality index on ipaVolumeHost, used to find packets related to a single host. This is sufficient for listing all relevant packets. It should also be sufficient when searching for a specific packet, there will be at most 10 packets per host in the usual case.
• A presence index on ipaVolumeKeyObsoletionTimestamp, used to identify obsolete keys that should be deleted. Ideally this should be a "b-tree index" (to allow searching for all obsolete packets), but that is not supported by the directory server.

IPA configuration

Additional attributes in ipaGuiConfig:

attributeType ( TBD
       NAME 'ipaObsoleteEscrowPacketLifetime' 
       DESC 'Number of days before an obsolete escrow packet is deleted (if a newer packet for the same volume is available)'
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27   # Integer
       SINGLE-VALUE
       X-ORIGIN 'IPA v2' )

Escrow packets with ipaVolumeKeyObsoletionTimestamp older than ipaObsoleteEscrowPacketLifetime are automatically deleted.

Note: This applies only to packets that were recognized by the IPA server as obsoleted by a newer packet. Obsoleted packets will be recognized by volume UUID (or perhaps other volume attribute that is sufficiently unique), which may not be available for all volume formats. If a volume format does not support reliable recognition of obsolete packets, the IPA server will never automatically mark a packet obsolete, and ipaObsoleteEscrowPacketLifetime will only affect packets that were manually marked obsolete by an administrator.

Todo: Make sure this limitation of automatic packet obsolescence is described in user documentation.

FIXME: current encryption certificate FIXME: all master keys

FIXME: separate LDAP/KRB identity for the "save escrow packet" operation.

Questions

• What ACIs protect ipaVolumeKey entries? What other access controls are enforced by IPA (apart from the necessity to known the master key passphrase?) Perhaps a cn=decryptescrowpacket,cn=taskgroups,cn=accounts,dc=... group?

Use case handling

(In all cases, the web interface should provide equivalent functionality to the command-line ipa interface.)

Get master key certificate

Executed by system administrators to retrieve the master key certificate used for encrypting escrow packets. The master key certificate itself, or the process of retreiving the certificate, is becomes a component of the escrow process.

• The system administrator uses the ipa command-line client to retrieve the certificate, e.g.:

ipa volume_key-current_cert > master.pem

• The client plugin simply retrieves the current value of the FIXME attribute. No authentication is necessary.

Send a packet to the server

Executed automatically as a part of IPA enrollment, or manually (by a site administrator, or by a local user). The system administrator's command could be e.g.

ipa volume_key-store volume [--create-random-passphrase] [--obsolete-older] [escrow_packet...]

• The client uses libvolume_key to retrieve volume properties, and if no escrow_packet is specified, it creates an escrow packet (for the "default" secret, usually a data encryption key). If --create-random-passphrase is specified, it sets up an additional random passphrase and created an additional escrow packet for it.
• For each packet (either specified on the command line, or created so far), the client uses XMLRPC with GSSAPI to connect to the IPA server, sending the volume attributes, the packet, and a flag corresponding to the "--obsolete-older" option. It uses either the current Kerberos identity of the user, or the machine identity (FIXME: do we need an option to use the machine identity even if the user has a TGT?).
• The server checks the identity of the client: if it is an user identity, it uses the Kerberos identity for LDAP authentication. If it is a machine identity, it uses a FIXME Kerberos identity for LDAP authentication.
• (The server may limit the number of saved packets, perhaps to 100 or 1000 per host, and refuse adding any more (logging the failure).)
• The server extracts host name from host properties, converts it into a DN for the host. If the client was authenticated with a machine identity, the server verifies the DN matches the authenticated identity.
• The server creates an ipaVolumeKey LDAP entry.
• If the "obsolete older" flag was specified, the server searches for other packets for the same host DN that do not have an ipaVolumeKeyObsoletionTimestamp, and checks if the volume identification for the new packet matches any of the other packets (probably matching mainly on the volume UUID, but the specifics can be dependent on the volume format). If it finds any matches, it sets the ipaVolumeKeyObsoletionTimestamp for the obsoleted timestamps to current date.

FIXME: can this be in Python?

List packets

Executed by a system administrator when recovery is necessary, to choose which packet to recover. In an interactive environment (e.g. WWW) the "list packets" and "recover a specific packet" operations can be combined.

• The client runs e.g.

ipa volume_key-list [--include-obsolete] hostname

• The client plugin converts hostname into a host DN, and uses it to search for matching ipaVolumeKey LDAP entries. The search filter matches the host DN, and, unless --include-obsolete is specified, matches absence of the ipaVolumeKeyObsoletionTimestamp attribute. The client loads all attributes except for ipaVolumeEscrowPacket.
• The client lists the packets, sorted by user-readable volume ID (e.g. the "volume_path" value of ipaVolumeInfo, other volume ID forms can be added later) and by creation time stamp, in that order. For each packet it shows at least the UUID, volume ID, secret type and creation time stamp. Options for other output formats and different orderings can be added (at least an option to show all available information would probably make sense).

"Make a packet available" to a system administrator

Executed by a system administrator when a recovery is necessary and a packet was selected, to decrypt it using the master key so that it can be copied to the client machine. In an interactive environment (e.g. WWW) the "list packets" and "recover a specific packet" operations can be combined.

• The client runs e.g.

ipa volume_key-get volume_uuid -o packet_file

where volume_uuid was chosen from results of a previous "list packets" operation.

• The client plugin asks the user to provide a master key passphrase.
• The client plugin uses XMLRPC to connect to the server, sending the volume UUID and master key password.

Note: The connection must use SSL or a similar mechanism to authenticate the server and to prevent eavesdropping.

• The server authenticates the user (it should be a "system administrator" permitted to access the key escrow data FIXME: specifics)
• The server logs the access.
• The server loads the packet from the ipaVolumeKey entry specified by the UUID, loads all encrypted master keys from FIXME. Each "encrypted master key" is a PKCS#12 container that contains a certificate and a private key.
• The server forks a separate process (to get a separate NSS context so that the master key is not available after this operation finishes).
• The child process creates a temporary NSS database, attempts to decrypt each PKCS#12 container using the provided user-provided passphrase (ignoring failures) and load the private key contained in the container. After loading the container, the child process attempts to decrypt the packet, and if successful, sends it back to the parent process. FIXME: prototype here
• The parent process receives the decrypted packet, waits until the child exits (or kills it), and wipes the temporary NSS database.
• The parent process sends the decrypted packet back to the client.
• The client plugin receives the decrypted packet.
• The client plugin asks the user for a passphrase to protect the packet, encrypts the packet using the passphrase, and writes it to the specified packet_file.

The system administrator copies the packet to the affected machine, and restores access (e.g. storing the packet on a flash drive, booting to rescue mode and using FirstAidKit).

Show secrets contained in a packet

Executed by a system administrator to display a passphrase, to tell it to the user (e.g. over a phone).

• The client runs e.g.

 ipa volume_key-secrets volume_uuid

where volume_uuid was chosen from results of a previous "list packets operation".

The operation proceeds exactly like in the above case of '"Make a packet available" to a system administrator', until the client plugin receives the decrypted packet.

• The client plugin loads the packet and prints the information it contains (including the "secret") to stdout.