<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Some excellent points, and thank you for being open to having the conversation - I know you don't have to, and it is appreciated.</div><div> </div><div><blockquote type="cite">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.</blockquote></div><div> </div><div>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.</div><div> </div><div>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.</div><div> </div><div>Lets look at this from another angle. Suppose I obtain a service keytab for my unprivileged web application (say HTTP/<a href="http://myapp01.example.com">myapp01.example.com</a>), 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.</div><div> </div><div>I'm even more curious about how I'd explain and justify this behaviour to clients. It's confusing, you know?</div><div> </div><div>Cheers</div><div> On 23 Mar 2016, at 09:48, Fraser Tweedale <<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>> wrote: </div><blockquote type="cite"><div>On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote: <blockquote type="cite">Hi Fraser, Martin and Alexander, </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Thanks for looking into this! For what it's worth, I think for this </blockquote><blockquote type="cite">particular use case, I'm leaning more towards Alexander when he said: </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite">I don't think you need to group services this way. For managing </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">services, and this means being able to issue certificates/keytabs for </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">them, we have hosts. By default a host that a service belongs to is </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">capable to modify userCertificate attribute of the service already, so I </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would expect it to be able to issue certificates with subject principal </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">corresponding to the service. </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite">If CAACL would follow the same logic by allowing hosts that manage </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">services to issue certificates with subject principals corresponding to </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">these services, that should be enough because, after all, these host </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">objects already have write permissions and can upload whatever </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">certificates they like to the service objects. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/ Alexander Bokovoy </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Personally, I was very surprised when I discovered that, even though a host </blockquote><blockquote type="cite">principal may manage a service principal, it is currently unable to request </blockquote><blockquote type="cite">a certificate for that service principal if the service principal doesn't </blockquote><blockquote type="cite">have specific access to the certificate profile, even though the host </blockquote><blockquote type="cite">principal may have access to the same certificate profile. In my mind the CA </blockquote><blockquote type="cite">ACL should be evaluated against the identity of the requestor, not the </blockquote><blockquote type="cite">issuee. As long as the requestor is allowed to request on behalf of the </blockquote><blockquote type="cite">issuee (achieved via the managedby attribute), then it should work. Now, if </blockquote><blockquote type="cite">I used the credentials of the service principal directly (say, with a </blockquote><blockquote type="cite">service keytab) to make the request (supposing the service principal wasn't </blockquote><blockquote type="cite">listed in the CA ACL), then denying the request would be the expected </blockquote><blockquote type="cite">behaviour (imo of course). </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Okay, so even though Alexander's suggestion might be more intuitive, </blockquote><blockquote type="cite">implementing service groups might be more feasible from a technical </blockquote><blockquote type="cite">standpoint, and I'm fairly sure this use case would also be solved by </blockquote><blockquote type="cite">implementing service groups. But, it would be painful without automember </blockquote><blockquote type="cite">regexp rules, so please don't forget this :D </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Cheers! </blockquote><blockquote type="cite"> </blockquote>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 <blockquote type="cite">On 2016-03-22 20:50, Fraser Tweedale wrote: </blockquote><blockquote type="cite"><blockquote type="cite">On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote: </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 03/22/2016 05:55 AM, Fraser Tweedale wrote: </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote: </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">... </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">To my fellow FreeIPA developers: are service groups a sensible RFE? </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Is there a reason why they have not been implemented? </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It *is* sensible RFE and it was actually already filed! </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="https://fedorahosted.org/freeipa/ticket/5277">https://fedorahosted.org/freeipa/ticket/5277</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Please feel free to add yourself to CC to receive updates or even help </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">us with </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">implementation. </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks, </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Martin </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Good to know... I've added myself to Cc and also filed an RFE for </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">enhancing CA ACLs with service groups once #5277 is implemented: </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://fedorahosted.org/freeipa/ticket/5753">https://fedorahosted.org/freeipa/ticket/5753</a> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers, </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fraser </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">-- </blockquote><blockquote type="cite">Manage your subscription for the Freeipa-users mailing list: </blockquote><blockquote type="cite"><a href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> </blockquote><blockquote type="cite">Go to <a href="http://freeipa.org">http://freeipa.org</a> for more info on the project </blockquote></div></blockquote></body></html>