[Samba] OTP authentication

[Alexander Bokovoy]

On Tue, Jan 20, 2015 at 6:55 PM,  <the2nd at otpme.org> wrote:
> On 2015-01-20 12:29, Alexander Bokovoy wrote:
>>
>> On Tue, Jan 20, 2015 at 1:03 PM,  <the2nd at otpme.org> wrote:
>>>
>>> On 2015-01-20 02:18, Andrew Bartlett wrote:
>>>>
>>>>
>>>> On Wed, 2015-01-14 at 17:53 +0100, the2nd at otpme.org wrote:
>>>>>
>>>>>
>>>>> it's not a certain project that i need this for. its a general question
>>>>> if this would be possible. i think OTPs are a good idea, also for
>>>>> windows logins.
>>>>>
>>>>> maybe some of the samba devs can shed some light on this?
>>>>
>>>>
>>>>
>>>> I'm seeing some work in upstream Heimdal, mirroring work being done in
>>>> the Kerberos standards community for this kind of thing.
>>>>
>>>> If your two-factor is a smart-card, then this is all OK - you can
>>>> already use a smart card to log into Samba.  Likewise, if you can create
>>>> a device that appears to be a smart card to windows (perhaps using a
>>>> backchannel to get short-term certificates), but unlocks with a OTP,
>>>> then you could use that.
>>>>
>>>> However, I've not seen anything that lets you use this at the standard
>>>> login screen.  If you can on the server-side, predict what the expected
>>>> OTP will be, then we have a better chance (we can just generate the
>>>> 'keys' on a just-in-time basis in our KDC plugin), but otherwise we have
>>>> to do whatever the Microsoft GUI allows.
>>>>
>>>> If your clients are not Windows, then things get more flexible, as we
>>>> could hook into the standard OTP support being added.
>>>>
>>>> I'm very interested in this area, and would love for Samba to be the
>>>> very best it can be in supporting improved security like this.
>>>>
>>>> Andrew Bartlett
>>>
>>>
>>>
>>>
>>> Thanks for the explanation. OTPme (the tool i'm currently writing:
>>> http://www.otpme.org) supports motp (http://motp.sf.net) as
>>> One-Time-Password tokens.
>>>
>>> The design of motp allows the server side to generate a list of OTPs (for
>>> a
>>> given time range) that could be used to verify the authentication
>>> request.
>>> E.g. for ntlm requests OTPme just generates a "response" for each OTP
>>> from
>>> the list and checks it against the response from the request.
>>>
>>> Some time ago i read something about using OTPs with kerberos
>>> preauthentication data. If i remember correctly preauthentication data
>>> was a
>>> string (e.g. timestamp) encrypted with the users key/OTP.
>>
>> Timestamp preauth is a norm in Kerberos environments now.
>>
>> With MIT Kerberos 1.11 we have now client-side support for OTP
>> Preauth, as described in RFC 6560. In MIT Kerberos 1.12 a server-side
>> support to have FAST OTP preauth that does OTP validation via RADIUS
>> protocol was added, we use it in FreeIPA with a local helper that
>> redirects validation requests from KDC to LDAP server bind requests
>> and LDAP server handles OTP auth method. Works very well.
>>
>> You can read more at
>> http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS and
>> http://www.freeipa.org/page/V4/OTP
>>
>> It would be nice if Heimdal would support RFC 6560 as it was supposed
>> in the original case of the work done Linus Nordberg which became OTP
>> support in MIT Kerberos. People asked this several times but I guess
>> the key part, as usual, is how to carve out required time for doing
>> it.
>
>
>
> thanks for the infos. i must admit that my knowledge of kerberos is not very
> deep but i'll try to read AND understand the RFCs :)
>
> maybe you can give me some hints.
>
> as far as i know in non-otp setups, kerberos works without transmitting the
> clear-text password.
>
> - client send preauth info (timestamp encrypted with the user password) to
> the server.
> - server verifies preauth info and sends tgt (encrypted with the user
> password) to user/client.
> - tgt can be used to get service tickets without re-auth with key/password
> - service tickets consist of two copies of the "session key". one encrypted
> with the password/key of the requested service (e.g. ldap) and one encrypted
> with the users password/key
> - user/client decrypts service key and creates a new "packet" that is
> crypted with the service key and contains a timestamp
> - service (e.g. ldap) receives both "packets" from the client/user and
> decrypts the packet that contains the "session key" (which is encrypted with
> its own service key)
> - service decrypts the second "packet" that contains a timestamp (which is
> encrypted with the session key)
>
> that's what i've learned some time ago reading some howtos. not the right
> terminology and not in the very detail but i guess in general thats how it
> works?
>
> please correct me if i'm wrong. :)
I'd refer you to
http://www.roguelynn.com/words/explain-like-im-5-kerberos/ for an easy
and picturesque explanation. :)

> maybe you can describe shorthand how otp preauth works with kerberos? i
> guess the otp needs to be transmitted to the kerberos server as you talk
> about validation via radius?
Yes, OTP token is transferred to the Kerberos KDC. In order to do that
securely, an encrypted FAST channel first needs to be created. FAST
actually supports multiple factors and OTP preauth relies on it.
As an example, SSSD in Fedora 21 does support OTP with Kerberos when
working against FreeIPA. It creates FAST channel using host/<fqdn>
principal and then uses this encrypted channel to perform OTP
preauthentication.

You can look at Linus Nordberg's presentation done in 2011 for details
and references:
http://www.kerberos.org/events/2011conf-interop/2011slides/2011kerberos_linus_nordberg.pdf

-- 
/ Alexander Bokovoy