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

[Alexander Bokovoy]

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 <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.
Sounds reasonable for me, thanks.
-- 
/ Alexander Bokovoy