[19588] in Kerberos_V5_Development
Re: Authentication strength and ticket policy
daemon@ATHENA.MIT.EDU (Matt Rogers)
Mon May 1 13:29:12 2017
To: undisclosed-recipients:;
MIME-Version: 1.0
In-Reply-To: <9816cad2-4aaa-c25b-2ade-4e8d47314fd3@mit.edu>
From: Matt Rogers <mrogers@redhat.com>
Date: Mon, 1 May 2017 13:28:30 -0400
Message-ID: <CAAeFVfzx3K=khp_NJhzkQWhtzB=zzo4g1ZGXE-YzXmkp5xRjpQ@mail.gmail.com>
Cc: krbdev <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Wed, Sep 14, 2016 at 11:51 AM, Greg Hudson <ghudson@mit.edu> wrote:
> On 09/13/2016 03:57 PM, Matt Rogers wrote:
>> On the call we briefly discussed the request to be able to influence
>> the ticket lifetime based on the preauth method used (ie. shorter
>> lifetimes for 2FA tickets). It would be good to continue the
>> discussion here.
>
> We could either implement this feature request completely within the
> core krb5 code, or merely make it possible to implement using plugin
> modules. The first option is difficult; our database schema isn't
> especially malleable, and making ticket lifetimes conditional on
> authentication indicators would require adding a lot of complexity to
> it. So I think it's more likely that we would enable the feature to be
> implemented using plugin modules.
>
> There are currently a few external interfaces for policy checking within
> the KDB interface. The relevant ones (check_policy_as and
> check_policy_tgs) are inadequate for this feature for two reasons: they
> do not receive the authentication indicators as an input, and they
> cannot influence ticket lifetimes as an output.
>
> Also, while having policy interfaces only within the KDB interface is
> adequate for FreeIPA and similar integrations, it makes it impossible to
> influence policy from a plugin module without also writing a complete
> KDB module. That's why I favor creating a separate KDC policy
> interface. Separating KDC policy interfaces from KDB interfaces also
> allows us to better control the complexity of the KDB interface.
>
> (Note that a single shared object can implement multiple module
> interfaces. Also, a policy module implemented within the same shared
> object as a KDB module could still access the database by retrieving the
> database handle from the krb5_context object.)
(Resurrecting this thread now that I'm able to look into this feature
some more). I've added some design considerations for the plugin
approach to a wiki page:
https://k5wiki.kerberos.org/wiki/Projects/KDC_TGS_Policy_plugin
Comments and edits are welcome!
Regards,
Matt
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
