[Samba] OTP authentication

[the2nd at otpme.org]

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

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?

regards
the2nd