[Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication

[Jan Cholasta]

On 11.1.2017 02:09, Fraser Tweedale wrote:
> On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote:
>> Hi Fraser,
>>
>> I have some rather inane comments. I guess Jan cholasta will do a more
>> thorough review of your design. See below:
>>
>> On 01/06/2017 09:08 AM, Fraser Tweedale wrote:
>>> Hi comrades,
>>>
>>> I have written up the high-level details of the FreeIPA->Dogtag
>>> GSS-API authentication design.  The goal is improve security by
>>> removing an egregious privilege separation violation: the RA Agent
>>> cert.
>>>
>>> There is a fair bit of work still to do on the Dogtag side but
>>> things are shaping up there and it's time to work out the IPA
>>> aspects.  The design is at:
>>>
>>>   http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication
>>
>> first of all, you link a internal document from publicly available design
>> page. you should prepare a publicly visible version of the Dogtag-side
>> design and link that.
>>
> Will do; thanks.
>
>> It would also be nice to have a high-level graphical representation of the
>> proposed CSR processing workflow. I think you can re-use the one that is in
>> the Dogtag part, omit the Dogtag internals and add IPA-specific parts.
>>
> I will definitely do this a bit later, once more details of IPA
> design are established.
>
>>>
>>> Right now, I need feedback about the Domain Level aspects: whether
>>> it is the right approach, whether there are mechanisms to perform
>>> update steps (specifically: LDAP updates and/or api calls) alongside
>>> a DL bump, or if there aren't, how to deal with that (implement such
>>> a mechanism, make admins do extra steps, ???).
>>>
>>
>> Is the DL bump really necessary? Are you sure we really can not just update
>> the profile configuration and let older Dogtag installation handle it
>> gracefully? IIRC we have done some profile inclusion work in 4.2 development
>> and on and never really bothered about older Dogtag understanding them.
>>
> The problem is that the new profiles will refer to plugins (i.e.
> classes) that do not exist in older versions of Dogtag.  Profile
> config is replicated, so if we upgrade profile config with old
> versions of Dogtag in the topology, it breaks them.
>
> I considered a mechanism where multiple versions of a profile exist
> in LDAP (i.e. multiple attribute values), and Dogtag picks the one
> that's "right" for it.  (An example of how to do this might be
> attribute tagging where tag indicates minimum version of Dogtag
> containing components used in that profile version, and Dogag picks
> the highest that it supports).  The advantage of such a mechanism is
> that we could use it for any future scenario where we introduce new
> profile components that we want to use in IPA.  The downside is that
> it significantly complicates profile management (including for
> administrators), and can result in the same profile having different
> behaviour on different Dogtag instances, which could be confusing
> and make it harder to diagnose issues.  Given the tradeoffs, I think
> a DL bump is preferable.

I don't like the prospect of having to bump DL every time a new 
component is introduced. This time it might be OK, because the new DL is 
apparently required for the RA -> GSSAPI change, but IMHO in general a 
change in a certificate profile does not warrant a DL bump.

I agree that maintaining multiple versions of a profile is not the way 
to go, but I think there are other options:

* Change `auth.instance_id` from `raCertAuth` to a new, IPA-specific 
`ipaAuth`. Configure `auths.instance.ipaAuth` in CS.cfg to behave 
exactly the same as `raCertAuth`. This will have to be done on all 
masters, including old ones, which can receive the change in a bug fix 
update (4.4.x). Then, on upgrade to new IPA with GSSAPI enabled Dogtag, 
change `auths.instance.ipaAuth` to use external script for 
authentication. Similar thing could be done for other profile components.

* Do not care about old masters. Update the profile and let certificate 
requests on old masters fail. This should be fine, as the situation 
where there are different version masters should be only temporary until 
all masters are upgraded. If an appropriate error is returned from 
cert-request, automated requests via certmonger will be re-attempted and 
will succeed once all masters are upgraded.

>
>> Anyway I guess we can call `certprofile-import' to load
>> ExternalProcessConstraint-enabled profile upon setting domain level to 2, we
>> just have to know where on the FS it is located.
>>
>>> Of course, any other general or specific feedback is welcome.
>>>
>>> Thanks,
>>> Fraser
>>>
>>
>> So if I understand correctly there will be no change in CA ACL management
>> interface and only the code which evaluates them will be factored out into
>> 'ipa-pki-validate-cert-request' command? Also, wouldn't it simpler if the CA
>> ACL evaluation was delegated to a separate API command instead?
>> ExternalProcessConstraint would then only ask IPA JSON api and process the
>> response.
>>
> There are no changes to CA ACL management interface as part of this
> design, but there are proposals to extend/rework it in future, e.g.
> #6424, #6425, #6426.
>
> Having a separate command for CA ACL evaluation is a good idea, and
> a clean refactoring target.  ExternalProcessConstraint is generic
> with no knowledge of IPA API, but 'pki-pki-validate-cert-request'
> can invoke the new API command.
>
> Thanks for your feedback, Martin!
>
> Cheers,
> Fraser
>


-- 
Jan Cholasta