[Samba] OTP authentication

[the2nd at otpme.org]

On 2015-01-20 19:24, Alexander Bokovoy wrote:
> 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. :)

thanks for this link. it explains much better than most stuff i found on 
the net. :)

but i think it misses the preauth step?


> 
>> 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.


is the "host/<fqdn> principal" the host principial of the client machine 
the user logs in from? and is this what is called "FAST armor key" in 
linus presentation?

if this is the case it would not be possible to kinit with an OTP from 
an client that does not have a host principal (/etc/krb5.keytab)? at 
least not if the OTP is not available to the kdc like described on slide 
14?

using the "The must-encrypt-nonce variant" from slide 13 should still be 
possible?

and my last question for now. is this supported by windows and can it be 
used with samba without the need of any client side installation? :)


> 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


thanks a lot. all this makes it much easier to understand. much more 
than reading the RFCs :)