[Freeipa-users] Host based 2FA ?

[Simo Sorce]

On Fri, 12 Dec 2014 13:49:24 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> On 12/12/2014 01:38 PM, Simo Sorce wrote:
> > On Fri, 12 Dec 2014 13:32:03 -0500
> > Dmitri Pal <dpal at redhat.com> wrote:
> >
> >> On 12/12/2014 01:27 PM, Simo Sorce wrote:
> >>> On Fri, 12 Dec 2014 13:17:18 -0500
> >>> Dmitri Pal <dpal at redhat.com> wrote:
> >>>
> >>>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
> >>>>> On Thu, 11 Dec 2014 18:30:06 -0500
> >>>>> Dmitri Pal <dpal at redhat.com> wrote:
> >>>>>
> >>>>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> >>>>>>> I'd like to be able to require 2FA on *certain* hosts and
> >>>>>>> allow just passwords on others.
> >>>>>>>
> >>>>>>> It seems you can check both "passwords" and "2FA" under the
> >>>>>>> user.
> >>>>>>>
> >>>>>>> I was hoping I could create a HBAC such that certain hosts
> >>>>>>> would only allow 2FA, but I can't see an obvious way to do
> >>>>>>> that.
> >>>>>>>
> >>>>>>> Is it possible?  Help on how would be great.  If not, feature
> >>>>>>> request?
> >>>>>>>
> >>>>>>> thanks,
> >>>>>>>
> >>>>>>> -t
> >>>>>>>
> >>>>>> We have several tickets:
> >>>>>>
> >>>>>> https://fedorahosted.org/freeipa/ticket/433
> >>>>>>
> >>>>>> https://fedorahosted.org/freeipa/ticket/3659
> >>>>>>
> >>>>>> https://fedorahosted.org/freeipa/ticket/4498
> >>>>>>
> >>>>>> If you see
> >>>>>> https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
> >>>>>> discussed this use case. And I was about to fork it as said
> >>>>>> but then I realized that there is not good way on the KDC to
> >>>>>> determine the host you are coming from. So IMO it should be a
> >>>>>> policy decision on SSSD. There are two options:
> >>>>>> - short term solution: allow SSSD to have a local overwrite to
> >>>>>> require OTP if server offers different options.
> >>>>>> - longer term solution: actually have a per host policy that is
> >>>>>> centrally managed that is fetched per host and enforced by
> >>>>>> SSSD.
> >>>>>>
> >>>>>> Before filing tickets I would like to hear opinions on the
> >>>>>> matter.
> >>>>> If we are using a FAST channel using the credentials of the host
> >>>>> then you may be able to know (probably requires changes in the
> >>>>> KDC to internally retain/convey the information).
> >>>>> This is possible via SSSD, but will not work via kinit done by a
> >>>>> generic user, so normal kinit's would require 2FA all the time.
> >>>>>
> >>>>> Simo.
> >>>>>
> >>>> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
> >>> Yes kinit can do FAST, but is cumbersome to manually do it.
> >>>
> >>>> May be in such setup we will require all clients to use FAST for
> >>>> the accounts that have several options configured.
> >>> It won't help, users do not have access to the host keys so they
> >>> can't do FAST with *those* keys.
> >>>
> >>>> Then we will know the principal used to armor the connection and
> >>>> can make policy decisions based on it.
> >>> We can do this with SSSD because it has access to the host key,
> >>> being a privileged process. Normal user's can't.
> >>>
> >>> Simo.
> >>>
> >> What about kinit working with GSS proxy in this case?
> >> Can that help?
> > No, kinit does not use GSSAPI.
> 
> I know it does not. What I mean is to use GSS proxy to as a proxy for 
> kinit to armor the request.
> Have an option for kinit to send user credentials to the local
> socket, make GSSproxy or SSSD do the work for him.

There is no way to convey this request over the GSS-Proxy protocol
either, sorry.

> If we are paranoid we can use SSL over this socket to pass the user 
> credential.
> But I am still not convinced we should care about this use case.

We should not care for the kinit case.

I think it is a potential good thing for the SSSD/pam_krb5 case (being
able to say that in order to log into a specific machine you need 2FA,
but on another less privileged one you can use single factor).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York