[Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

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 <ftweedal at 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 at 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.com at EXAMPLE.COM', if there is a SAN dnsName
`www.example.com', we look for `HTTP/www.example.com at EXAMPLE.COM' in
its aliases.

Does this sound reasonable?

No other GeneralName types shall be checked against principal
aliases, unless/until we support SRVName.

Cheers,
Fraser