Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[Fraser Tweedale]

On Wed, Mar 23, 2016 at 04:37:43PM +1100, a.fed...@earsdown.com
wrote:
> Some excellent points, and thank you for being open to having the
> conversation - I know you don't have to, and it is appreciated.
> 
> > Profiles which are allowed for a host principal (representing
> > physical or virtual machines) are not necessarily the same
> > profiles that should be used for service principals.  This is
> > why CA ACLs must be executed against the issuee principal.
> 
> 
> Certmonger uses the host credential (from the host keytab) to make
> all requests on behalf of all service principals of a given
> machine, right?
>
That's correct.

> So if that machine is compromised then so too are
> all keys/certificates issued to that machine. If I think a machine
> is more likely to become compromised, I'd want to lock down the
> Certificate Profiles available to that whole machine.
>
Protecting keys is a separate issue from the the CA being able to
answer the question "can I issue certs to principal P using profile
X?".

> Even if I
> end up using different profiles for different services on the same
> machine, I'm still forced to trust certmonger to use the right
> profile for each request.
> 
CA ACLs are stored and evaluated on the IPA server.  If Certmonger
uses the "wrong profile for a request", the worst that will happen
is CA ACL enforcement will deny the request.  I do not see how any
special trust resides in Certmonger in this scenario.

> So, even with future sub-CAs (this excites me btw), I'm just not
> sure I understand the security benefit of evaluating CA ACLs
> against the subject/issuee of the request, when (as you say)
> directory ACIs are already doing this.
> 
Directory ACIs govern which principals can request a certificate on
behalf of a subject principal.  CA ACLs govern which profile(s) are
valid for such a request.  These are quite different things, and
both are important.

(I'm glad you're excited about sub-CA support; I am too!)

> Lets look at this from another angle. Suppose I obtain a service
> keytab for my unprivileged web application (say
> HTTP/myapp01.example.com), which is needed to authenticate web
> clients via kerberos/gssapi. The app also needs x509 certificates
> for TLS, which is handled by certmonger. Given the current
> approach of CA ACLs, it would be possible for my unprivileged
> web-app (if it were to become compromised) to use its service
> keytab to request certificates from IPA directly, which is
> undesirable, but I'd have no way of stopping it.
> 
The same is true for rogue user or host credentials.  The scope is
even bigger for compromised host credentials, since a host principal
can request certificates both for itself and for any services it
manages.

> I'm even more curious about how I'd explain and justify this
> behaviour to clients. It's confusing, you know?
> 
I am open to any ideas about how to explain this more clearly.  The
best approach I can think of is to explain that CA ACLs are about
answering, "what kinds of certificate can the CA issue to subject
principal 'P'?", and emphasising that that is a very different
question from, "who can request a certificate on behalf of subject
principal 'P'?".

Thanks,
Fraser

> Cheers
> 
> > On 23 Mar 2016, at 09:48, Fraser Tweedale 
> > wrote:
> > 
> >> On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote: Hi
> >> Fraser, Martin and Alexander,
> >> 
> >> Thanks for looking into this! For what it's worth, I think for
> >> this particular use case, I'm leaning more towards Alexander
> >> when he said:
> >> 
> >>> I don't think you need to group services this way. For
> >>> managing services, and this means being able to issue
> >>> certificates/keytabs for them, we have hosts. By default a
> >>> host that a service belongs to is capable to modify
> >>> userCertificate attribute of the service already, so I would
> >>> expect it to be able to issue certificates with subject
> >>> principal corresponding to the service.
> >> 
> >>> If CAACL would follow the same logic by allowing hosts that
> >>> manage services to issue certificates with subject principals
> >>> corresponding to these services, that should be enough
> >>> because, after all, these host objects already have write
> >>> permissions and can upload whatever certificates they like to
> >>> the service objects.  -- / Alexander Bokovoy
> >> 
> >> Personally, I was very surprised when I discovered that, even
> >> though a host principal may manage a service principal, it is
> >> currently unable to request a certificate for that service
> >> principal if the service principal doesn't have specific access
> >> to the certificate profile, even though the host principal may
> >> have access to the same certificate profile. In my mind the CA
> >> ACL should be evaluated against the identity of the requestor,
> >> not the issuee. As long as the requestor is allowed to request
> >> on behalf of the issuee (achieved via the managedby 

Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[a . fedora]

Some excellent points, and thank you for being open to having the conversation 
- I know you don't have to, and it is appreciated.

> Profiles which are allowed for a host principal (representing
> physical or virtual machines) are not necessarily the same profiles
> that should be used for service principals.  This is why CA ACLs
> must be executed against the issuee principal.


Certmonger uses the host credential (from the host keytab) to make all requests 
on behalf of all service principals of a given machine, right? So if that 
machine is compromised then so too are all keys/certificates issued to that 
machine. If I think a machine is more likely to become compromised, I'd want to 
lock down the Certificate Profiles available to that whole machine. Even if I 
end up using different profiles for different services on the same machine, I'm 
still forced to trust certmonger to use the right profile for each request.

So, even with future sub-CAs (this excites me btw), I'm just not sure I 
understand the security benefit of evaluating CA ACLs against the 
subject/issuee of the request, when (as you say) directory ACIs are already 
doing this.

Lets look at this from another angle. Suppose I obtain a service keytab for my 
unprivileged web application (say HTTP/myapp01.example.com), which is needed to 
authenticate web clients via kerberos/gssapi. The app also needs x509 
certificates for TLS, which is handled by certmonger. Given the current 
approach of CA ACLs, it would be possible for my unprivileged web-app (if it 
were to become compromised) to use its service keytab to request certificates 
from IPA directly, which is undesirable, but I'd have no way of stopping it.

I'm even more curious about how I'd explain and justify this behaviour to 
clients. It's confusing, you know?

Cheers

> On 23 Mar 2016, at 09:48, Fraser Tweedale  wrote:
> 
>> On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote:
>> Hi Fraser, Martin and Alexander,
>> 
>> Thanks for looking into this! For what it's worth, I think for this
>> particular use case, I'm leaning more towards Alexander when he said:
>> 
>>> I don't think you need to group services this way. For managing
>>> services, and this means being able to issue certificates/keytabs for
>>> them, we have hosts. By default a host that a service belongs to is
>>> capable to modify userCertificate attribute of the service already, so I
>>> would expect it to be able to issue certificates with subject principal
>>> corresponding to the service.
>> 
>>> If CAACL would follow the same logic by allowing hosts that manage
>>> services to issue certificates with subject principals corresponding to
>>> these services, that should be enough because, after all, these host
>>> objects already have write permissions and can upload whatever
>>> certificates they like to the service objects.
>>> --
>>> / Alexander Bokovoy
>> 
>> Personally, I was very surprised when I discovered that, even though a host
>> principal may manage a service principal, it is currently unable to request
>> a certificate for that service principal if the service principal doesn't
>> have specific access to the certificate profile, even though the host
>> principal may have access to the same certificate profile. In my mind the CA
>> ACL should be evaluated against the identity of the requestor, not the
>> issuee. As long as the requestor is allowed to request on behalf of the
>> issuee (achieved via the managedby attribute), then it should work. Now, if
>> I used the credentials of the service principal directly (say, with a
>> service keytab) to make the request (supposing the service principal wasn't
>> listed in the CA ACL), then denying the request would be the expected
>> behaviour (imo of course).
>> 
>> Okay, so even though Alexander's suggestion might be more intuitive,
>> implementing service groups might be more feasible from a technical
>> standpoint, and I'm fairly sure this use case would also be solved by
>> implementing service groups. But, it would be painful without automember
>> regexp rules, so please don't forget this :D
>> 
>> Cheers!
> The CA ACLs solve a different part of the authorisation puzzle for
> certificates: what profiles (or, in the future, (sub-)CAs) may be
> used to issue certs to a given subject is a different question from
> which entities can request certificates on behalf of the subject.
> Profiles which are allowed for a host principal (representing
> physical or virtual machines) are not necessarily the same profiles
> that should be used for service principals.  This is why CA ACLs
> must be executed against the issuee principal.
> 
> It is best to implement service groups then support them in CA ACLs.
> 
> Final note: directory ACIs allow hosts to request certificates for
> services they manage.  The overall authorisation for cert issuance
> depends on *both* the directory ACIs and CA ACLs.
> 
> Cheers,
> Fraser
> 
>>> On 2016-03-22 20:50, 

Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[earsdown]

Hi Fraser, Martin and Alexander,

Thanks for looking into this! For what it's worth, I think for this 
particular use case, I'm leaning more towards Alexander when he said:



I don't think you need to group services this way. For managing
services, and this means being able to issue certificates/keytabs for
them, we have hosts. By default a host that a service belongs to is
capable to modify userCertificate attribute of the service already, so 
I

would expect it to be able to issue certificates with subject principal
corresponding to the service.



If CAACL would follow the same logic by allowing hosts that manage
services to issue certificates with subject principals corresponding to
these services, that should be enough because, after all, these host
objects already have write permissions and can upload whatever
certificates they like to the service objects.
--
/ Alexander Bokovoy


Personally, I was very surprised when I discovered that, even though a 
host principal may manage a service principal, it is currently unable to 
request a certificate for that service principal if the service 
principal doesn't have specific access to the certificate profile, even 
though the host principal may have access to the same certificate 
profile. In my mind the CA ACL should be evaluated against the identity 
of the requestor, not the issuee. As long as the requestor is allowed to 
request on behalf of the issuee (achieved via the managedby attribute), 
then it should work. Now, if I used the credentials of the service 
principal directly (say, with a service keytab) to make the request 
(supposing the service principal wasn't listed in the CA ACL), then 
denying the request would be the expected behaviour (imo of course).


Okay, so even though Alexander's suggestion might be more intuitive, 
implementing service groups might be more feasible from a technical 
standpoint, and I'm fairly sure this use case would also be solved by 
implementing service groups. But, it would be painful without automember 
regexp rules, so please don't forget this :D


Cheers!

On 2016-03-22 20:50, Fraser Tweedale wrote:

On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote:

On 03/22/2016 05:55 AM, Fraser Tweedale wrote:
> On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
...
> To my fellow FreeIPA developers: are service groups a sensible RFE?
> Is there a reason why they have not been implemented?

It *is* sensible RFE and it was actually already filed!

https://fedorahosted.org/freeipa/ticket/5277

Please feel free to add yourself to CC to receive updates or even help 
us with

implementation.

Thanks,
Martin


Good to know... I've added myself to Cc and also filed an RFE for
enhancing CA ACLs with service groups once #5277 is implemented:
https://fedorahosted.org/freeipa/ticket/5753

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] Certificate profiles and CA ACLs for service principals

[Fraser Tweedale]

On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote:
> On 03/22/2016 05:55 AM, Fraser Tweedale wrote:
> > On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
> ...
> > To my fellow FreeIPA developers: are service groups a sensible RFE?
> > Is there a reason why they have not been implemented?
> 
> It *is* sensible RFE and it was actually already filed!
> 
> https://fedorahosted.org/freeipa/ticket/5277
> 
> Please feel free to add yourself to CC to receive updates or even help us with
> implementation.
> 
> Thanks,
> Martin
>
Good to know... I've added myself to Cc and also filed an RFE for
enhancing CA ACLs with service groups once #5277 is implemented:
https://fedorahosted.org/freeipa/ticket/5753

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] Certificate profiles and CA ACLs for service principals

[Martin Kosek]

On 03/22/2016 05:55 AM, Fraser Tweedale wrote:
> On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
...
> To my fellow FreeIPA developers: are service groups a sensible RFE?
> Is there a reason why they have not been implemented?

It *is* sensible RFE and it was actually already filed!

https://fedorahosted.org/freeipa/ticket/5277

Please feel free to add yourself to CC to receive updates or even help us with
implementation.

Thanks,
Martin

-- 
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] Certificate profiles and CA ACLs for service principals

[Alexander Bokovoy]

On Tue, 22 Mar 2016, Fraser Tweedale wrote:

On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:

Hi all,

Firstly, a big thank you to everyone who works on the FreeIPA project - you
guys are my heroes.

Let's talk about the new Certificate Profile and CA ACL feature and some use
cases that should be possible but I'm struggling to implement. Hopefully I'm
just missing something obvious, and if not, perhaps someone here can suggest
a workaround. I'll do my best to keep this as brief and concise as possible,
and I'm grateful for any help given.

Some background:

Our environment is composed of AWS EC2 instances running CentOS 7 (7.2.1511
+ ipa-server-4.2.0-15, fully patched afaik).
Our instances acquire three certificates during creation, which is achieved
via user-data/cloud-init. The first certificate is linked to service
principal puppet/$HOSTNAME, the second is linked to HTTP/$HOSTNAME, and the
third is the default NSS-based certificate linked to the host principal (via
ipa-client-install --request-cert).
We want our long-lived EC2 instances to acquire certificates using the
standard caIPAserviceCert profile. Examples would be database servers,
puppetmasters, etc.
We use EC2 spot instances via auto-scaling groups heavily - these are our
short-lived instances. For example, application servers, etc.
We want our short-lived instances to acquire certificates with a really
short validity (like 3 days). Read on to find out why.

Our applications login to their respective postgresql databases using mutual
SSL auth (i.e. IPA CA issued certificates). Sadly, postgresql has to be
restarted every time the CRL is updated (see section 17.9.2 of postgresql
doc). If the CRL expires, postgres stops authenticating clients via SSL.
This means we're forced to either turn off CRL checking in postgres entirely
or have really long CRL validity times - we're going to go with the latter.
It also means application servers will need to be issued with short-lived
certificates (and must not have access to the caIPAserviceCert profile)
because we can't realistically restart our production database servers every
time an application server's certificate gets revoked.

The use case:

1. Suppose we have a hostgroup called "database_servers" and a host called
"db01" that is a member.
3. Modify the default CA ACL "hosts_services_caIPAserviceCert" to restrict
access to the "database_servers" hostgroup only (i.e. no services or users
allowed).
4. Attempt to request a certificate (via ipa-getcert) from the "db01" server
(which is in the "database_servers" hostgroup). The request should be linked
(via -K) to a service principal like postgres/$HOSTNAME (service to be
created beforehand).
5. This currently fails with CA_REJECTED ca-error: Server at
https://ipa.example.com/ipa/xml denied our request, giving up: 2100 (RPC
failed at server.  Insufficient access: Principal
'postgres/db01.example@example.com' is not permitted to use CA '.' with
profile 'caIPAserviceCert' for certificate issuance.).

Is this the intended behaviour? If so, is there any way to avoid having to
add each and every individual service principal directly to the CA ACL?
After all, we have hostgroups to avoid the mess of adding individual hosts,
right? Well... each host would have several service principals...and we
don't seem to have a way of grouping them.

Thanks in advance,

~earsdown


Hi,

This is expected behaviour.  The CA ACLs control which profiles may
be used with which subject principals, which in your use case is a
service principal.  Adding the host or hostgroup to the CA ACL does
not apply to service principals, even though the hostname may be the
same.

For grouping services, FreeIPA currently does not have a "group"
object for service principals.  So at the moment, either every
applicable service must be added to the ACL, or you can allow all
services with the command: 'ipa caacl-mod  --servicecat=all'.

I hope that explains the situation clearly.  Let me know your
follow-up questions!

To my fellow FreeIPA developers: are service groups a sensible RFE?
Is there a reason why they have not been implemented?

I don't think you need to group services this way. For managing
services, and this means being able to issue certificates/keytabs for
them, we have hosts. By default a host that a service belongs to is
capable to modify userCertificate attribute of the service already, so I
would expect it to be able to issue certificates with subject principal
corresponding to the service.

If CAACL would follow the same logic by allowing hosts that manage
services to issue certificates with subject principals corresponding to
these services, that should be enough because, after all, these host
objects already have write permissions and can upload whatever
certificates they like to the service objects.
--
/ Alexander Bokovoy

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