On Fri, 2017-03-24 at 11:52 +0100, Martin Babinsky wrote: > On Fri, Mar 24, 2017 at 10:53:49AM +0200, Alexander Bokovoy wrote: > >On pe, 24 maalis 2017, Martin Babinsky wrote: > >> On Thu, Mar 23, 2017 at 04:46:20PM +0200, Alexander Bokovoy wrote: > >> > On to, 23 maalis 2017, Simo Sorce wrote: > >> > > On Thu, 2017-03-23 at 16:08 +0200, Alexander Bokovoy wrote: > >> > > > On to, 23 maalis 2017, Martin Babinsky wrote: > >> > > > >Hi List, > >> > > > > > >> > > > >TL;DR we have to handle FAST channer establishment when KDC is not > >> > > > >issued > >> > > > >PKINIT keypair > >> > > > > > >> > > > >I have spent some time studying and fixing bugs/regressions caused > >> > > > >by > >> > > > >incomplete consideration of PKINIT and anonymous principal setup > >> > > > >regarding to > >> > > > > > >> > > > >* replicas standed up against old (3.0.0) masters > >> > > > >* domain level 0 topologies > >> > > > >* CA-less deployments > >> > > > > > >> > > > >I want to discuss the impact of these findings on existing > >> > > > >functionality and > >> > > > >how to fix them so that 4.5.1 release will be more usable and free > >> > > > >of subtle > >> > > > >but serious bugs (more on this later). > >> > > > > > >> > > > >From conversation from Alexander and Simo it follows that anonymous > >> > > > >PKINIT > >> > > > >feature is supposed to be used in domain level 1 deployments > >> > > > >because only these > >> > > > >guarantee the presence of the features (CA ACLs and custom > >> > > > >certificate > >> > > > >profiles) which allow for issuing certificates suitable for PKINIT > >> > > > >authentication. This leads to the following considerations: > >> > > > > > >> > > > >* on DL0 enforce no_pkinit on server/replica deployments > >> > > > >* during upgrade of DL0 deployments, do not issue PKINIT > >> > > > >certificates > >> > > > >* during upgrade of DL1 deployments issue PKINIT certs > >> > > > >* extend ipa-server-certinstall to install/issue PKINIT > >> > > > >certificates after > >> > > > > DL0/DL1 ugrade (have to be manually). > >> > > > > > >> > > > >However, I found out that the only case when anonymous PKINIT > >> > > > >actually works is > >> > > > >for fresh DL1 server install and upgrade and install of 4.5.0 > >> > > > >replica against > >> > > > >4.5.0 master in DL1. The following use-cases either fail to install > >> > > > >or leave > >> > > > >the system with unusable password auth (e.g. WebUI login): > >> > > > > > >> > > > >* setting up 4.5 replica against <4.5 master fails during anonymous > >> > > > > principal setup[1] (ticket states domain level 0, but DL1 is also > >> > > > > affected) > >> > > > >* setting up server-replica with `no_pkinit` option (CA-full or > >> > > > >CA-less) > >> > > > > leaves the installation without non-working WebUI as anonymous > >> > > > > PKINIT does > >> > > > > not work (ticket incoming) > >> > > > >* If we restrict DL0 installs to force no_pkinit[2] we will be left > >> > > > >with > >> > > > > whole topologies where anonymous PKINIT does not work, so no > >> > > > > WebUI auth > >> > > > > for them > >> > > > > > >> > > > >We now have to decide how to properly support or avoid non-PKINIT > >> > > > >deployments. > >> > > > >The current code which handles armoring of password auth > >> > > > >requests[3] does not > >> > > > >actually work without PKINIT certificates, the fallback mechanism > >> > > > >still fails > >> > > > >to obtain armor ccache[4]. > >> > > > > > >> > > > >I have concluded that for non-PKINIT cases we have > >> > > > >to use the old way to armor TGT request (i.e. establish fast > >> > > > >channel by > >> > > > >kinit as service principal), but this means that the framewrok has > >> > > > >to use a > >> > > > >service principal whose keytab it can read and use. After privilege > >> > > > >separation, > >> > > > >however, we do not have direct access to HTTP keytab so how should > >> > > > >we proceed > >> > > > >in this case? We definitely need to discuss this further. > >> > > > > > >> > > > >Please state your suggestions and comments, and sorry for the long > >> > > > >mail. > >> > > > Thanks, Martin, for the thorough analysis. > >> > > > > >> > > > I need to clarify *why* we need working Anonymous PKINIT. There are > >> > > > two > >> > > > separate needs here: > >> > > > > >> > > > - Enable clients with no access to a separate key to be usable for > >> > > > 2FA > >> > > > accounts. This can be best explained as to support Kerberos auth > >> > > > from > >> > > > non-enrolled machines or machines where no SSSD is in use. In such > >> > > > cases we cannot use another credentials to create FAST channel and > >> > > > pass 2FA creds with kinit. > >> > > > > >> > > > - Enable IPA framework to perform password-based login for 2FA. With > >> > > > privilege separation we don't have access to HTTP/... principal's > >> > > > keytab anymore (gssproxy does) and neither GSSAPI nor gssproxy > >> > > > support FAST channel wrapping for explicitly specified > >> > > > password+2FA > >> > > > token. > >> > > > > >> > > > For DL0 we do not officially support PKINIT, so first case is not > >> > > > relevant. However, second case is what we need even on DL0 because > >> > > > otherwise IPA framework does not work, as you have witnessed. > >> > > > > >> > > > We thought that we could solve this problem by re-using anonymous > >> > > > principal as 'normal' principal -- by fetching its keytab and > >> > > > authenticating with the keys from it. But for anonymous principal MIT > >> > > > Kerberos library does verification of the session key and requires > >> > > > it to > >> > > > be provided with PKINIT PA DATA when there is no wrapping principal > >> > > > keys. > >> > > > > >> > > > See RFC 6112 section 4.1: > >> > > > https://tools.ietf.org/html/rfc6112#section-4.1 > >> > > > > >> > > > ---- > >> > > > The Kerberos client can use the client's long-term keys, the > >> > > > client's > >> > > > X.509 certificates [RFC4556], or any other pre-authentication > >> > > > data, > >> > > > to authenticate to the KDC and requests an anonymous ticket in an > >> > > > AS > >> > > > exchange where the client's identity is known to the KDC. > >> > > > > >> > > > If the client in the AS request is anonymous, the anonymous KDC > >> > > > option MUST be set in the request. Otherwise, the KDC MUST > >> > > > return a > >> > > > KRB-ERROR message with the code KDC_ERR_BADOPTION. > >> > > > ---- > >> > > > > >> > > > Corresponding code in MIT Kerberos is this: > >> > > > https://github.com/krb5/krb5/blob/master/src/lib/krb5/krb/get_in_tkt.c#L157 > >> > > > > >> > > > So, using keytab for anonymous principal does not work. We either can > >> > > > have another principal to perform wrapping or actually fix PKINIT for > >> > > > DL0 for the purpose of IPA framework. > >> > > > > >> > > > The latter is easy to achieve. Certmonger maintains two local CAs: > >> > > > SelfSign and 'local': > >> > > > > >> > > > # getcert list-cas > >> > > > [....] > >> > > > CA 'SelfSign': > >> > > > is-default: no > >> > > > ca-type: INTERNAL:SELF > >> > > > next-serial-number: 01 > >> > > > CA 'local': > >> > > > is-default: no > >> > > > ca-type: EXTERNAL > >> > > > helper-location: /usr/libexec/certmonger/local-submit > >> > > > > >> > > > The first one self-signs whatever request you provide, the second one > >> > > > signs it with a locally generated CA which is unique to each host. > >> > > > The > >> > > > latter one doesn't perform any checks and simply signs the request. > >> > > > > >> > > > Obviously, relying on certmonger's local CA to provide PKINIT to > >> > > > other > >> > > > IPA clients does not scale. But we already estblished we wouldn't do > >> > > > that. In IPA framework which runs on the very same host as KDC, we > >> > > > can > >> > > > have access to the same public key KDC would be using for itself and > >> > > > can > >> > > > kinit with it as an anchor: > >> > > > > >> > > > kinit -X x509_anchor=/path/to/local-ca.crt -n > >> > > > > >> > > > This approach allows us to avoid any modification to /etc/krb5.conf > >> > > > on > >> > > > IPA master. An IPA framework would only need to have access to the > >> > > > public key of local CA. And local CA is something certmonger provides > >> > > > since its first run. > >> > > > > >> > > > Yes, we'll need to manage upgrades from DL0 to DL1 for PKINIT. In > >> > > > practice this will mean we have to: > >> > > > > >> > > > - replace local CA-issued KDC certificate if we were upgraded to > >> > > > become > >> > > > IPA-managed CA > >> > > > > >> > > > - replace local CA-issued KDC certificate with externally provided > >> > > > KDC > >> > > > certificate if we were upgraded and provided with explicit > >> > > > certificates > >> > > > > >> > > > This is certainly doable and primary benefit is that we wouldn't > >> > > > need to > >> > > > have any fallbacks anymore. We would always use Anonymous PKINIT > >> > > > within > >> > > > the IPA framework and be done with it. > >> > > > >> > > Just to recap the reason to support PKINIT locally is for supporting > >> > > 2FA > >> > > in the WebUI which is a hard requirement. > >> > Correct. > >> > > >> > > Using the local CA will make this work for local logins ONLY and this > >> > > is > >> > > OK. > >> > > The kinit command should really be called with this option: > >> > > x509_anchor=/var/kerberos/krb5kdc/cacert.pem so it will always work > >> > > regardless of what CA cert is there (the local one or the real CA one). > >> > The option is -X x509_anchor=... > >> > > >> > > The only issue will be handling SELinux issues, if those are a problem > >> > > we can also simply copy the local-ca.crt > >> > > in /var/lib/ipa/api/pkinit-ca.crt and always call kinit with that file. > >> > I think we can do that in pre-start hook in httpd.service.d/ipa.conf > >> > > >> > > We would need to make sure we copy there the correct CA cert for the > >> > > job > >> > > (certmonger's local-ca crt if no pkinit is enabled or whatever CA cert > >> > > we are given if pkinit is enabled). > >> > > > >> > > >> > -- > >> > / Alexander Bokovoy > >> > >> Ok so let's forget for a moment about the clients and focus on framework > >> and > >> PKINIT. We then have two options how to handle FAST wrapping: > >> > >> 1.) use a custom principal for FAST channel, e.g. ipaapi/`hostname` > >> This is analogous to how were things done before privilege > >> separation/PKINIT work. A plus is that you configure it once and it > >> works regardless of whether PKINIT is configured properly or not. A > >> minus is that when PKINIT is configured you are still using > >> one special mechanism for FAST/2FA for the webui while the rest of > >> clients are happily using anonymous principal. Another minus is > >> that we > >> introduce another n principals (where N is number of masters) which > >> will (at least initially) be used only for FAST channel generation > >> and > >> nothing else. > >> > >> 2.) use anonymous principal for FAST channel. The advantage is that when > >> PKINIT is configured properly (DL1), we use the same mechanism for > >> FAST/2FA in the whole topology regardless of the use case (although > >> as > >> we already discussed we will still have to pass custom anchor > >> location > >> during password auth in the framework). A disadvantage is that in > >> no-PKINIT case we would have to use certmonger's local CA to issue > >> PKINIT cert, fetch the local CA cert and store it somewhere in > >> (e.g. in > >> /var/kerberos/kdc/cacert.pem). On DL-bump or if someone wishes to > >> enable PKINIT we have to re-issue the certs by IPA and replace the > >> CA > >> cert by IPA-issued one (this can be made part of > >> ipa-server-certinstall). > >> > >> I feel I can not really decide which approach is better. The first one is > >> consistent with regard to PKINIT status and domain level but inconsistent > >> with > >> the client vs. server FAST channel generation mech. The second one uses > >> common > >> mechanism everywhere, but in no-PKINIT case we must 'fake' the anonymous > >> PKINIT > >> by specially issued certificates which feels a bit hacky to me. > >Both Simo and me are for (2). > > > >Note that we are not faking anything in the case of DL0. It is real > >PKINIT with limited functionality only. > >-- > >/ Alexander Bokovoy > > Right, since I myself am ambivalent on the issue I will update your PKINIT > design page (or you can update it) on Monday and implement the agreed > procedure > for DL0/no-PKINIT handling next week. I have some code ready for the fixes in > upgrade/replication so Iihave already tampered with the affected codebase. > > If somebody disagrees with the proposed solution he has today and Monday to > voice his concerns.
I think 2) is superior in that it reduces the number of mechanisms we need to use and allows us to remove completely the fallback to the anon keytab (which doesn't work) and reduces the number of secrets we need to store on the system, one less keytab (also compared to 1). So I am firmly for 2) Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
