Talk:Disk encryption key escrow in IPA

Dpal 02:24, 4 June 2009 (UTC)

I think there is some confusion about the XMLRPC, python and what is available and how things work with IPA.
When we talk about client we talk about a member of the IPA domain. In IPA v1 the clients had all the python commands installed so there was no difference between client and machine from which you can run CLI. In v2 this will change. In v2 it should not be assumed that the CLI is available on every machine. The CLI will be a separately installable package for the administration of the IPA. It will be recommended to install it only where needed. This all means that the the host that needs to escrow its keys will not have those utilities. It will have utilities to enroll the machine. This utility will be written (most likely) in C to be able to cover a broad set of platforms we plan to eventually support. So the client of the keys escrow would have to either use:

• Its own (most likely C) implementation of the XML-RPC so that it would talk to the server using XML-RPC protocol. This approach is something that is being explored by the entollment utility implementation. The issue that I see is that it would have to support kerberos over GSSAPI. Seems like a heavy lifting to me.
• The alternative would be to use LDAP protocol and submit the escrow packets using the ldapmodify or similar utility. It natively supports kerberos and GSSAPI so the solution would be much simpler. The issue with this approach is that it is a bit (as the previous one too) heavy for the other use cases related to key management. For example for use case when the IPA needs to be accessed from a preboot partition.
• Explore KMIP protocol. Unfortunately I have not have a chance to read the specs yet but I plan to as soon as I can. It the KMIP proves to be the way to go based on the specs then I envision that we would have to stand up a KMIP server that would have to be able to handle different requests one of which would be key escrow from the client. I am not sure that for other use cases related to management of the already saved keys we need to go though such KMIP server. It looks like that these use cases can be solved by the usual ipa commands. Those would leverage our framework. For them there is no need to have a special user account like ipaXMLRPCServiceAccount. The authenticated user that tries to perform an operation would have to have rights to access the DS entry and its attributes. This all controlled on the ACI level and enforced by DS itself. We would have to see if we need a special account for the KMIP server or not and how it would connect to the IPA. I can't say anything about this until I read the specs. If we go with KMIP than on the client we would implement KMIP client. I assume there is some way to secure the channel for the KMIP client to talk to server and I assume the KMIP client can be pretty light weight so that it can connect from the pre-boot partition.

So to summarize: the whole section after the schema definition seems a bit off to me since it talks about the XMLRPC and makes some assumtions about it that are not valid.

Mitr 15:12, 8 June 2009 (UTC)

All of the described operations except for "Send a packet to the server" are performed by system administrators, who will have the Python CLI installed. So the requirement of XMLRPC for some of the operations should not be a problem.

This leaves the "Send a packet to the server" operation. XMLRPC (as opposed to plain LDAP) is necessary for 1) automatically obsoleting older escrow packets, and 2) limiting the number of packets store per host, to avoid the DoS we discussed earlier.

• Marking packets as obsolete ("1)") is primarily an UI feature, to limit possible clutter in the output. In practice showing the latest one or two packets per host will most likely work just as well as the obsolescence mechanism, so we can drop the feature easily.
• I don't know how to avoid the DoS without XMLRPC ("2)") or other "smart" server side.

We can probably avoid authenticating the client - as long as the number of packets per host is limited, and submitting a packet does not automatically obsolete an older packet (i.e. dropping the automatic packet obsolescence feature, probably just dropping the obsolescence feature altogether).

So, the options are:

• A: Use an XMLRPC client in C, with GSSAPI negotiation. No changes to the server infrastructure are necessary. There is [1] with some support for GSSAPI negotiation, perhaps worth testing.
• B: Drop the obsolescence feature, use an XMLRPC client in C, without client authentication. Small changes to the server infrastructure are necessary, to allow LDAP connections as ipaXMLRPCServiceAccount.
• C: Use an alternative protocol for the "send packet" operation, using GSSAPI. This can be full KMIP, something KMIP-based, or something custom and simple, e.g. a HTTP POST. In any case a client and server have to be implemented from scratch. (FWIW, KMIP currently considers transport and authentication out of scope, it recommends using TLS.)
• D: Drop the obsolescence feature, use an alternative protocol for the "send packet" operation, without client authentication. This can be full KMIP, something KMIP-based, or something custom and simple, e.g. a HTTP POST.
• E: Drop the obsolescence feature, use LDAP, and limit the number of packets server-side, using a RHDS plug-in (if it's possible).
• F: Drop the obsolescence feature and DoS limitation, use LDAP, rely on the creatorsName attribute to identify the perpetrator, and on "real world" policies to deter them.

I'm think "B" makes most sense: it requires the smallest amount of special-case code in C without major impact on functionality.

Rcritten 19:50, 11 June 2009 (UTC)

In response to the questions

• By default everyone (including anonoymous) will have read access to all these attributes and admin would have write access. Any attributes that we don't want to grant read access to by default we would add to an existing ACI for this purpose. It is currently:

aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";)

• For those attributes that we want to be able to delegate access to, yes we can create taskgroups to handle those.
• We'll need a taskgroup that will grant add access to create the initial entry that any machine that would want to do escrow would need to be a member of (or rather, the rolegroup that is allowed to do the task).

I don't understand the ipaXMLRPCServiceAccount. Is this the principal for the machine or do we need another whole type of member/user for this? When are these created?

Mitr 15:01, 12 June 2009 (UTC)

ipaXMLRPCServiceAccount is supposed to be created during IPA installation; only code that runs as part of the XMLRPC server can use this identity. It has two main proposed uses:

• Provide a "LDAP user" identity to be used in place of machine accounts - is this necessary at all, will the LDAP server be able to treat a machine account as an user identity for purposes of access control?
• Provide an user identity that is allowed to read ipaEscrowKey, without letting the system administrators "allowed to handle escrow packets" to read the attribute. If the system administrators, who know the "master key passphrase", could read the ipaEscrowKey attribute, they could decrypt the master key, keep it on their machine, and decrypt any escrow packet without being audited. The proposal is to use the ipaXMLRPCServiceAccount identity to read ipaEscrowKey inside the XMLRPC server, and deliver only the results of the decryption to the system administrator "allowed to handle escrow packets". The idea is similar to the set-UID-root unix_chkpwd program - let the users work with ipaEscrowKey without giving them direct access.