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

[Michael Ströder]

Fil Di Noto wrote:
> In my imagination, I see IPA for whatever reason comes accross a cert
> it signed in the past and decides it needs to compare the SAN to the
> directory. Then it sees the SAN doesn't have an associated principal
> in the directory. Who does IPA trust? (the directory obviously). IPA
> says, "is this SAN in the directory? No. Did I sign the cert? Yes.
> Should I trust the cert? Yes because I signed it."

Speaking purely from the PKI perspective without detailed knowledge about 
FreeIPA:

If the IPA directory is the only assured source of truth then the CA must revoke
the cert because its knowledge about the assertion made in the cert (this public
key belongs to this entity) cannot be verified anymore.

Note that the assertion made in a cert has to be valid for the *complete*
validity period of the cert, not only at the time of cert issuance.

=> If in doubt then revoke.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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

Re: [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 11:02:44AM -0700, Fil Di Noto wrote:
> On Mon, Oct 24, 2016 at 9:55 PM, 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  
> >> 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/ 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.
> 
> Help me understand. Assuming that the SAN in the CSR are
> valid/intended/non-malicious, can you give me an example scenario
> where sanity becomes a problem? Is IPA going to examine the cert at
> some point in the future and get confused when it doesn't recognize
> the entries in the SAN field?
> 
> In my imagination, I see IPA for whatever reason comes accross a cert
> it signed in the past and decides it needs to compare the SAN to the
> directory. Then it sees the SAN doesn't have an associated principal
> in the directory. Who does IPA trust? (the directory obviously). IPA
> says, "is this SAN in the directory? No. Did I sign the cert? Yes.
> Should I trust the cert? Yes because I signed it."
> 
> I've got a hundred related questions, but maybe an example would help
> me answer them myself.
> 
A CA must ensure that the assertions it makes have some relationship
to (its view of) reality.  If it issues a cert with `google.com' in
the SAN, the holder of the key can pretend to be `google.com' to
anyone who trusts the CA.  If `alice' tricks an admin into issuing a
cert with `b...@example.com' as a SAN rfc822Name, then alice can
pretend to be Bob.  Entities consuming these certs do not
necessarily have access to the IPA directory to check if the data on
the cert makes sense - they will simply trust whatever assertions
are 

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

[Fil Di Noto]

On Mon, Oct 24, 2016 at 9:55 PM, 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  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/ 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.

Help me understand. Assuming that the SAN in the CSR are
valid/intended/non-malicious, can you give me an example scenario
where sanity becomes a problem? Is IPA going to examine the cert at
some point in the future and get confused when it doesn't recognize
the entries in the SAN field?

In my imagination, I see IPA for whatever reason comes accross a cert
it signed in the past and decides it needs to compare the SAN to the
directory. Then it sees the SAN doesn't have an associated principal
in the directory. Who does IPA trust? (the directory obviously). IPA
says, "is this SAN in the directory? No. Did I sign the cert? Yes.
Should I trust the cert? Yes because I signed it."

I've got a hundred related questions, but maybe an example would help
me answer them myself.

>
> 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?
>
>
>> > The problem is slightly exacerbated in that 99% of the time you
>> > really want to issue service certs, but FreeIPA does not permit the
>> > creation of a service entry without a corresponding host entry.  So
>> > you end up with spurious host entries that do not correspond to
>> > actual hosts.  I have previously asked about relaxing this
>> > restriction.  The idea was rejected (for reasons I don't remember).
>>
>> To be fair, I don't think I ever 

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

[Simo Sorce]

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  
> >> > > 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/ 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 

Re: [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  
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/ 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.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to 

Re: [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  
> > > 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/ 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 

Re: [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 Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:

On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale  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/ 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.

--
/ Alexander Bokovoy

--
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

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

[Fraser Tweedale]

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  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/ 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?


> > The problem is slightly exacerbated in that 99% of the time you
> > really want to issue service certs, but FreeIPA does not permit the
> > creation of a service entry without a corresponding host entry.  So
> > you end up with spurious host entries that do not correspond to
> > actual hosts.  I have previously asked about relaxing this
> > restriction.  The idea was rejected (for reasons I don't remember).
> 
> To be fair, I don't think I ever read specifically that a Host in IPA
> was supposed to represent a single computer. But I imagine that the
> majority of people who are using it thought that was the case, at
> least at first. I don't think it would take much abstraction to
> maintain that logical representation for administrators.
> 
> >> If this actually is a necessity and is not likely to change, I think it
> >> would be beneficial to administrators to be able to manage "Hosts" that
> >> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
> >> are actually enrolled computers. They could be managed in a similar fashion
> >> to SUDO rules, like maybe:
> >>
> >>
> >>
> >> Alias Hosts = a single name
> >>
> >> Alias Host Groups = groups of names
> >>
> >> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
> >>
> >>
> >>
> >> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
> >> (and some corresponding "ipa aliashost-*" CLI) 

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

[Fil Di Noto]

On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale  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/ 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 problem is slightly exacerbated in that 99% of the time you
> really want to issue service certs, but FreeIPA does not permit the
> creation of a service entry without a corresponding host entry.  So
> you end up with spurious host entries that do not correspond to
> actual hosts.  I have previously asked about relaxing this
> restriction.  The idea was rejected (for reasons I don't remember).

To be fair, I don't think I ever read specifically that a Host in IPA
was supposed to represent a single computer. But I imagine that the
majority of people who are using it thought that was the case, at
least at first. I don't think it would take much abstraction to
maintain that logical representation for administrators.

>> If this actually is a necessity and is not likely to change, I think it
>> would be beneficial to administrators to be able to manage "Hosts" that
>> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
>> are actually enrolled computers. They could be managed in a similar fashion
>> to SUDO rules, like maybe:
>>
>>
>>
>> Alias Hosts = a single name
>>
>> Alias Host Groups = groups of names
>>
>> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
>>
>>
>>
>> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
>> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
>> under policy.
>>
> Now that we have kerberos principal aliases, we might be able to
> leverage that, perhaps even directly for service principals.  Any
> devs want to chime in on this idea?
>
> Cheers,
> Fraser

-- 
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

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

[Alexander Bokovoy]

On ma, 24 loka 2016, Fraser Tweedale 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/ 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.

The problem is slightly exacerbated in that 99% of the time you
really want to issue service certs, but FreeIPA does not permit the
creation of a service entry without a corresponding host entry.  So
you end up with spurious host entries that do not correspond to
actual hosts.  I have previously asked about relaxing this
restriction.  The idea was rejected (for reasons I don't remember).

The host entries are not "spurious" as you call them. They are objects
that participate in the access control. Services always belong to hosts
and are managed by them. Whether there are DNS entries corresponding to
the controlling objects is irrelevant, their primary use is to be used
as something that could be defined as owning the service. The fact that
host object is also a service in itself (for host/) is an
obvious optimization for Kerberos infrastructure

As you know, on x.509 certificate level there are no differences between
services running on the same host, so technically all Kerberos services
could share the same certificate associated with the host that controls
them. You could just keep the certificate in the host entry and be done
with it. This, of course, has own issues -- mostly related to rotation
of the certificates and access to the private keys from multiple
applications -- but this has nothing to do with the way how IPA presents
hosts in the database.


--
/ Alexander Bokovoy

--
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

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

[Fraser Tweedale]

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/ 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.

The problem is slightly exacerbated in that 99% of the time you
really want to issue service certs, but FreeIPA does not permit the
creation of a service entry without a corresponding host entry.  So
you end up with spurious host entries that do not correspond to
actual hosts.  I have previously asked about relaxing this
restriction.  The idea was rejected (for reasons I don't remember).

> 
> 
> If this actually is a necessity and is not likely to change, I think it
> would be beneficial to administrators to be able to manage "Hosts" that
> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
> are actually enrolled computers. They could be managed in a similar fashion
> to SUDO rules, like maybe:
> 
> 
> 
> Alias Hosts = a single name
> 
> Alias Host Groups = groups of names
> 
> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
> 
> 
> 
> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
> under policy.
>
Now that we have kerberos principal aliases, we might be able to
leverage that, perhaps even directly for service principals.  Any
devs want to chime in on this idea?

Cheers,
Fraser

-- 
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

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

[Fil Di Noto]

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/ 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?



If this actually is a necessity and is not likely to change, I think it
would be beneficial to administrators to be able to manage "Hosts" that
correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
are actually enrolled computers. They could be managed in a similar fashion
to SUDO rules, like maybe:



Alias Hosts = a single name

Alias Host Groups = groups of names

Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups



I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
(and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
under policy.
-- 
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