[Freeipa-devel] OTP Sync Client Design

[Nathaniel McCallum]

On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote:
> On 05/14/2014 05:23 PM, Nathaniel McCallum wrote:
> > On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote:
> >> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote:
> >>> Occasionally OTP tokens get out of sync with the server. When this
> >>> happens, the user or an admin need to synchronize the token. To this
> >>> end, we landed server-side synchronization support, which is a simple
> >>> bind with a custom control. This all works with my sample test script.
> >>>
> >>> Client support is proving a bit more difficult. In the ideal world, the
> >>> client would contact LDAP directly and perform the operation. This would
> >>> make a man in the middle attack difficult and we can ensure encryption
> >>> over the entire operation.
> >>>
> >>> However, browsers, without server-side assistance, cannot perform this
> >>> operation from javascript. This means that, in this case, the first
> >>> factor and two second factors must be transmitted to the FreeIPA server
> >>> and then proxied to 389. Is this an acceptable compromise?
> >> Does Javascript have a way to encrypt things?
> >> May be we should do some encryption before sending the values over the wire?
> >> On the other hand we are OK with the form based login so I am not sure
> >> if there is any value.
> > Yes, but I agree there is not a lot of value.
> >
> >> We might have some logic related to permissions i.e. members of the
> >> admin group can only sync on server but I am not sure that is something
> >> we should consider out of box.
> >>
> >> In any way IMO it should be a separate page, other than login page that
> >> can be accessed by anyone. It should be visible outside firewall like
> >> other OTP vendors do. This would allow to use a mobile device to sync up
> >> a token (and potentially change the password).
> > This would be nice.
> >
> >>> This command also needs to be accessible *without* an existing user
> >>> login since, if a user's token is out of sync, the user can't login. Is
> >>> it possible to expose such an API? If so, how? Both "ipa env" and "ipa
> >>> ping" seem to require kinit, so I don't see any obvious examples.
> >> IMO SSSD should probably have a way to sync the token.
> >>  From usability point of view it should be a part of the standard stock
> >> client software, not a part of the IPA client or ipa tools.
> >> It should probably have a good UI integration too if token is used to
> >> login into a laptop.
> > SSSD has direct access to LDAP right? If so, it can just do a bind with
> > the added control. That is actually the easiest way.  Trying to access
> > via a third API is probably actually more difficult.
> >
> >> So for that to happen we should probably expose this interface over D-BUS.
> >> This is what we talked about with the desktop folks some time ago.
> >> The attached is the doc and there are diagrams at the end that show what
> >> we decided needs to be done.
> >> Similar to that one can provide a simple otp-sync application that will
> >> sync using command line (but on the other hand may be it should just
> >> warp curl?).
> > How exactly we expose this in GDM is indeed a much more complicated
> > question and needs to be part of the next phase of integration. I've
> > CC'd jhrozek for this part.
> >
> >> Some thoughts came up while writing this mail:
> >>
> >> a) We can go the complex path and provide password and sync capabilities
> >> in every client. This is a lot of work based on my past experience and
> >> can't be done quickly. See the complexity of the diagrams and flows in
> >> the attached doc. And may be it should not be.
> > The synchronization needs to be added to whatever layer has access to
> > the LDAP server. How it is exposed from there is specific to each
> > application.
> >
> >> b) May be IPA should provide a portal/proxy to do self service token
> >> sync and/or password change. This can be a URL. It should be possible to
> >> access it externally outside the firewall. It should be bullet proof.
> >> But then we need just one interface and one call and we can use it from
> >> mobile device or some other system on the internet to self service the
> >> token and then pass authentication. IMO that would save us a lot of time
> >> and effort. I know other OTP vendors went this path and were quite
> >> successful.
> > +1. This solves the VPN bootstrapping problem.
> >
> > However:
> >
> > 1. It should be available by default in the FreeIPA installation with a
> > link from the login page. This is just a matter of product polish.
> >
> > 2. In the case of a user logging into GDM, we have a bootstrapping
> > problem that they can't login without a token, and they can't sync their
> > token without logging into a browser. GDM/SSSD probably needs to support
> > this natively.
> 
> True but not from day one.
> This is why I mentioned a mobile device.
> Keeping in mind that FreeOTP is on the mobile device and there is a good 
> chance that the person who will have a Linux laptop will have a mobile 
> device.
> They can also call a helpdesk and ask the helpdesk engineer to sync the 
> token for them.
> That means that there should be an admin interface that would not 
> require the first factor just two codes.

Yup. Agreed. Just thinking big picture.

Nathaniel