[Freeipa-users] Host based 2FA ?

[Nathaniel McCallum]

On Fri, 2014-12-12 at 14:46 -0500, Dmitri Pal wrote:
> On 12/12/2014 02:40 PM, Nathaniel McCallum wrote:
> > On Fri, 2014-12-12 at 13:07 -0500, 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.
> 
> I do not understand how kinit will require 2FA if kinit does not use 
> FAST (because it does not have access to the host keys).
> OTP is possible only over the armored tunnel.
> 
> > This was my exact thought. But this technically isn't HBAC so much as
> > "choose preauth mechs based upon the principal used to secure the FAST
> > channel." It would also be somewhat useless if using anonymous pkinit to
> > secure the FAST channel.
> >
> > Besides, long-term, we want FAST to go away. It is too cumbersome.
> 
> But there will be other way to create armor tunnel and you would need 
> some other principal in the exchange, right?

No. Long-term, with PAKE preauth, the second factor will be dynamically
encrypted in the session key calculated from two public keys (client and
server) and the long-term shared secret. There will be no other
principal involved.

> So what would be a short term and long term solution?
> SSSD override seems like a simple thing to do.
> AFAIR we already design it couple years ago but I suspect not 
> implemented yet.

Long-term, there is no way to restrict this from the KDC-side.

As I see it, long-term we have auth indicators, optional 2FA and PAKE
+OTP. The user can be configured for password OR password+otp. Then SSSD
can be told via something like an HBAC which it should prompt for. But
this would be purely voluntary since the KDC will allow both logins.

Having different policies based on the source of a message is always bad
security design because such information can never be trusted by the
recipient.

Nathaniel