On Tue, 2016-10-25 at 09:02 +0300, Alexander Bokovoy wrote: > On ti, 25 loka 2016, Fraser Tweedale wrote: > >On Tue, Oct 25, 2016 at 08:01:59AM +0300, Alexander Bokovoy wrote: > >> On ti, 25 loka 2016, Fraser Tweedale wrote: > >> > On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote: > >> > > On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> > >> > > wrote: > >> > > > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote: > >> > > >> Hello, > >> > > >> > >> > > >> > >> > > >> > >> > > >> I would like to better understand why IPA requires SAN (subject > >> > > >> alternative > >> > > >> name) entries to have a backing host record. In order to sign a > >> > > >> certificate > >> > > >> with a SAN that corresponded to a user friendly CNAME I had to add > >> > > >> a host > >> > > >> record (ipa host) for that DNS name (use force option to create > >> > > >> without an > >> > > >> A/AAAA record) as well as a service principle. > >> > > >> > >> > > >> > >> > > >> > >> > > >> I'm sure I'm not alone when I say I don't like doing that because > >> > > >> it means > >> > > >> that a "Host" in FreeIPA is not a computer, it's a host record that > >> > > >> may or > >> > > >> may not be the only record that corresponds to a computer. It gets > >> > > >> confusing. > >> > > >> > >> > > >> > >> > > >> > >> > > >> I assume things are this way to ensure integrity at some level. But > >> > > >> I can't > >> > > >> picture it. What is the potential danger of simply bypassing the > >> > > >> host/principal checks and just signing the certificate with > >> > > >> whatever SAN > >> > > >> field we like? > >> > > >> > >> > > > In this specific case, it is because certmonger requests service > >> > > > certificates with host credentials. Therefore it is not just human > >> > > > administrators issuing certs. And we MUST validate SAN against > >> > > > information in the directory (the only "source of truth" available > >> > > > to the CA / IPA cert-request command). Otherwise you could put e.g. > >> > > > `google.com' into SAN, and we would issue the cert, and that would > >> > > > be Very Bad. > >> > > > > >> > > > >> > > In my case it's always human administrators issuing certs. I can see > >> > > how validation is a great way to prevent a scenario like the one you > >> > > described. But couldn't that be accommodated by tinkering with the > >> > > roles/privileges so that you could impose the restriction on external, > >> > > less-trusted applications but allow a trusted human administrator to > >> > > bypass it? > >> > > > >> > > Admin group by default would be nice. It would be unfortunate if > >> > > someone added a service account to the admin group, but I don't see > >> > > that as justification for ruling it out. How many other poor security > >> > > decisions has someone made already before they decided to add a > >> > > service account to the domain admin group? To that I would say that > >> > > degree of administrative negligence is not something that the project > >> > > should design around. But, I don't work at RedHat and I don't have to > >> > > take the support calls so my opinion means nothing. > >> > > > >> > > But if I'm an admin, enforcing the SAN restriction doesn't prevent me > >> > > from doing anything I couldn't already do by creating a couple host > >> > > records. It's just making things difficult for admins who ultimately > >> > > are securely deploying a service. > >> > > > >> > The question is not really one of privilege, but sanity. FreeIPA > >> > has to make sure that certs issued by it correspond to the CA's view > >> > of reality, i.e. what is in the FreeIPA directory, at the time the > >> > request is made. IMO to disable these checks for human users with a > >> > particular permission is a mistake waiting to happen. > >> > > >> > Yes, enforcing the restriction forces a human to put to created the > >> > needed objects before the cert request will be considered valid. > >> > Not a bad thing, IMO. > >> > > >> > All this said, I think there is a valid RFE in allowing Kerberos > >> > principal aliases to be consulted when validating a CSR. This would > >> > mean you do not have to create new objects, just add more principal > >> > names to the existing one. I filed a ticket: > >> > > >> > https://fedorahosted.org/freeipa/ticket/6432 > >> > > >> > Alexander, Simo, what do you think? > >> Certainly principal aliases should be checked if they were asked to be > >> in SAN. The question is what type of the SAN extension should be > >> considered for them in addition to Kerberos principal. The aliases are > >> stored in their full format (alias@REALM), so either you need to do full > >> match or consider dropping the realm for some types. This needs to be > >> clarified before any implementation happens. > >> > >Right, UPN and KR5PrincipalName can be checked as-is. > > > >We should check dnsNames by affixing around the dnsName the same > >service type (e.g. `HTTP') and realm as the nominated principal, and > >looking for that in the aliases. e.g. for nominated principal > >`HTTP/web.example....@example.com', if there is a SAN dnsName > >`www.example.com', we look for `HTTP/www.example....@example.com' in > >its aliases. > > > >Does this sound reasonable? > > > >No other GeneralName types shall be checked against principal > >aliases, unless/until we support SRVName. > Sounds reasonable for me, thanks.
+1 Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
