Difficult agent mTLS configuration

Is your an issue a feature request? If so, please raise it as an enhancement

Environment

• OS / version:
• Processor architecture:
• TPM Manufacturer:
• Keylime version: current latest 37d338f

Description

keylime agent uses the following options for mTLS

# The name of the RSA key that Keylime should use for protecting shares of U/V.
rsa_keyname = tci_rsa_key

# The name of the X509 certificate that is used for mTLS. Uses the rsa_keyname as a key.
mtls_cert = tci_mtls_cert

# The CA that signs the client certificates of the tenant and verifier.
# If set to default it tries to use /var/lib/keylime/cv_ca/cacert.crt
keylime_ca = default

keylime verifier uses

# mTLS configuration for connecting to the agent.
# Set 'agent_mtls_cert' to 'CV' for using the CV CA for the connections.
agent_mtls_cert = CV
agent_mtls_private_key =
agent_mtls_private_key_pw =

and tenant also uses

# mTLS configuration for connecting to the agent.
# Set 'agent_mtls_cert' to 'CV' for using the CV CA for the connections.
agent_mtls_cert = CV
agent_mtls_private_key =
agent_mtls_private_key_pw =

There are the following issues with this configuration:

1. rsa_keyname and mtls_cert assumes file names or paths relative to /var/lib/keylime/secure. This is not mentioned and in contradiction to keylime_ca or mTLS related options of tenant or verifier which assume absolute paths.

2. absolute paths for cloud agent should be also supported

3. when a file cannot be accessed due to incorrect path the message should be printed visibly (Warning or Error, currently only Debug).

4. agent mtls certificate needs to be self-signed, this fact is not documented

5. naming convention for agent options - should have similar names as tenant and verifier. keylime_ca should be rather named ca_cert or mtls_ca_cert.

6. verifier and tenant do not mention which CA cert is being used if ‘CV’ is not set.

[ansasaki]

@THS-on From my point of view, yes, #1068 addresses the issues pointed here

[ansasaki]

I think most of the options related with keys/certificates configurations are confusing or not clear:

In cloud_verifier section:

• tls_dir: could be more explicit, like ca_dir, cv_ca_dir, or verifier_ca_dir
• registrar_tls_dir: similar to above, could be registrar_ca_dir or registrar_access_ca_dir. I understand it is difficult to select a name as it is not usual to have the option to select different keys/certs to use for each individual connection. The description comments could also be more explicit (e.g. The following options set the keys and certificates the verifier will use as a client to connect to the registrar.)
• registrar_my_cert: could be registrar_access_cert or something similar. The confusing part is to understand why we have registrar options in cloud_verifier section.
• registrar_private_key: the most confusing option, made me ask “why would any entity know other entity’s private key?”. This again could be something like registrar_access_private_key. A comment specifying explicitly the purpose of this option, like mentioned above, could clarify it.
• agent_mtls_cert, agent_mtls_private_key, agent_mtls_private_key_pw: these are not as confusing as the registrar related options, but consistency on naming would be nice. A clear and explicit comment about the purpose would be a plus.

In tentant section:

• All above applies here
• There are no options to set the keys/certificates used when connecting to the verifier. I understand my_cert and private_key are used in this case, but again some consistency is missing.
  • This also shows that probably https://github.com/keylime/keylime/issues/681 is still a valid issue.