From Fedora Project Wiki

Revision as of 16:40, 1 June 2009 by Mitr (talk | contribs) (Created page with '== Data in LDAP == === Escrow packet storage === Stored in <code>ipaUniqueID=..., cn=volume_keys, dc=...</code>. The following information is stored per each packet: {| borde...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

An additional attribute 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.

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?

Other data

  • A separate NSS database that stores the master key, perhaps in /etc/ipa/key_escrow. (A separate NSS database is necessary because AFAIK NSS gives access to all private keys as soon as the database passphrase is known, and we want a separate packet decryption passphrase.)
  • A well-known location for a certificate of the master key, e.g. /etc/ipa/key_escrow/cert.crt. The certificate should be available from the web interface as well.

This naturally handles cases where more than one master key is generated over time (e.g. a stronger key is generated to replace an older, weak, key): all private keys are stored in the NSS database, so the server can decrypt packets encrypted using any of the keys, and the well-known certificate location contains the certificate of the key that is expected to be used by clients.

The master key / certificate must be set up, either during IPA server set up, or later (e.g. after an upgrade of the IPA server from an older version).

Questions

  • Should the master key certificate be signed by some CA? A CA integrated with the IPA server, or an external CA? Should the certificate contain any specific field values?
  • Is there currently an interactive procedure for IPA server upgrade to which could the master key / certificate set up be added? Or will this be a separate step?
Retrieved from "https://fedoraproject.org/w/index.php?title=Disk_encryption_key_escrow_in_IPA&oldid=105300"