On Wed, Mar 23, 2016 at 04:37:43PM +1100, a.fed...@earsdown.com
> 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.
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
> 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
> 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
> > On 23 Mar 2016, at 09:48, Fraser Tweedale <ftwee...@redhat.com>
> > 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, 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
> Manage your subscription for the Freeipa-users mailing list:
> Go to http://freeipa.org for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project