Bug 1031116

I think this is invalid. The CA certificate is securely retrieved from LDAP using provided credentials.

If the certificate is retrieved over HTTP for some reason (it is a fallback) then in fact we do prompt the user.

(In reply to Rob Crittenden from comment #1)
> I think this is invalid. The CA certificate is securely retrieved from LDAP
> using provided credentials.
> 
> If the certificate is retrieved over HTTP for some reason (it is a fallback)
> then in fact we do prompt the user.

What security can LDAP provide over HTTP when the identity of the server can not be verified by the client? The credentials identify user to the server but the server identity should be established _before_ sending those credentials.

FWIW, this is the log from ipa-client install from the machine:

'''
# ipa-client-install --domain <domain>
WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd

Discovery was successful!
Hostname: djasa-ws.<domain>
Realm: <DOMAIN>
DNS Domain: <domain>
IPA Server: idm.<domain>
BaseDN: <dc=domain>

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for admin@<REALM>
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=<REALM>
    Issuer:      CN=Certificate Authority,O=<REALM>
    Valid From:  Fri Nov 15 11:33:50 2013 UTC
    Valid Until: Tue Nov 15 11:33:50 2033 UTC

Enrolled in IPA realm <REALM>
Created /etc/ipa/default.conf
New SSSD config will be created
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm <REALM>
Hostname (djasa-ws.<domain>) not found in DNS
DNS server record set to: djasa-ws.<domain> -> 10.34.130.218
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.
'''

As the root certificate was not present on the machine, ipa-client-install should have added CA certificate fingerprint to info printed before confirmation prompt.

The CA is retrieved from LDAP using GSSAPI using Kerberos so we have mutual authentication. See this, http://www.freeipa.org/page/CVE-2012-5484

We could probably reorder the prompts but I doubt this would lead to added security as the majority of user's eyes glaze over when they are presented with a certificate. This is the reason that Firefox switched to a 3-click CA override.

OK, let me rephrase scenario where I still see MITM potential:
*  in IPA with self-signed/root CA, I have permissions that allow me to enroll machines
* I am administrator of a client machine and I don't have a certificate on trusted medium (say offline flash) but I know (have printed) its fingerprint
* the network between client machine and IPA is managed by someone else --> not to be trusted

So how exactly is ensured that ipa-client-install connects to real IPA server and not to an impostor/MITM with the same domain/realm name?

> We could probably reorder the prompts but I doubt this would lead to added
> security as the majority of user's eyes glaze over when they are presented
> with a certificate. 

Keep the prompt itself as-is. Please just add cert fingerprint(s) to the info above prompt (in case if server cert or some of CAs in the signing chain aren't trusted of course).

There is a distinction between "user can verify something but ignores it" and "user can not easily verify the stuff"...

Mutual authentication prevents connecting with an imposter/MITM.

Displaying the fingerprint is useful and that can be done but it is has the potential to be clumsy because the certificate is retrieved AFTER prompting the user for their password, so the steps are:

- "Do you want to connect this server?"
- "What's your password?"
- "Is this CA ok?"

I really don't see a case where someone would want to answer no here, unless some admin loaded the wrong CA certificate into the IPA ldap server.

Right, thanks for the discussion. I think that the final answer is - yes, we can add the fingerprint to the certificate information, but it still is just a FYI for an admin, not something he can immediately act upon.

Is this change still useful for you or should we close the RFE as is?

I discussed this issue with David in person.

Given that we connect over untrusted network, one could set up a rogue IPA server, forge DNS records and let the client connect to the wrong one. But it seems to me that the rogue KDC would either have to know admin's password so that kinit+LDAP auth succeeds or it would have to be forged to always accept admin's login and then get Kerberos credentials from him. It is an interesting question, also adding Simo to chime in and tell if we need to improve ipa-client-install.

What we could certainly do, is to print the CA cert fingerprint, this is the least we can do. We may even print it before asking to continue with installation, but we would have to get the certificates from LDAPS/LDAP port (after STARTTLS).

I would leave to Simo to confirm but to the best of my knowledge you can't forge a KDC. Protocol implies mutual authentication and client would reject response from the server that does not have the right keys at its possession.

(In reply to Martin Kosek from comment #7)
> I discussed this issue with David in person.
> 
> Given that we connect over untrusted network, one could set up a rogue IPA
> server, forge DNS records and let the client connect to the wrong one. But
> it seems to me that the rogue KDC would either have to know admin's password
> so that kinit+LDAP auth succeeds or it would have to be forged to always
> accept admin's login and then get Kerberos credentials from him.

This is not possible, the ticket received by the client can be decrypted only with admin credentials, in order to provide a ticket that the admin can decrypt you need to know the admin's password, if you do not know the admin password, the ticket will fail to decrypt on the client and the whole installation fails.

> It is an
> interesting question, also adding Simo to chime in and tell if we need to
> improve ipa-client-install.

I do not see any improvement possible in this regard.

> What we could certainly do, is to print the CA cert fingerprint, this is the
> least we can do.

Sure as an informational message this is ok, I have no objections.

> We may even print it before asking to continue with
> installation, but we would have to get the certificates from LDAPS/LDAP port
> (after STARTTLS).

We should print it when we retrieve it unconditionally.
For the cases where we fall back to fetching from HTTP then we should change the code to warn we are doing so, then download the CA cert, show the fingerprint, and only after we show it ask if the admin recognizes the cert signature and wants to proceed.

Switching to download from LDAP (and esp using STARTTLS) when we do not have a way to trust the CA is only a complication of the code (you need to instruct tls to ignore untrusted certs) that has no useful purpose, except perhaps risking of forgetting to flip the switch to trust certs once the admin accepted the CA cert and thus opening to potential attacks. Stick to HTTP, if the CA cert is untrusted nothing else will change/improve the situation nutil the admin accepts the CA cert.

Thanks for information. I think this RFE boils down just to printing the fingerprint which would be useful when the certificate is downloaded via HTTP. I will open an upstream ticket.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4077

Thank you taking your time and submitting this request for Red Hat Enterprise Linux. The request was cloned to the upstream tracker long time ago (see link to the upstream ticket above), but it was unfortunately not given a priority neither in the upstream project, nor in Red Hat Enterprise Linux.

Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.

To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you. Please note that you can still track this request or even offer help in the referred upstream Trac ticket to expedite the solution.