[Samba] OTP authentication

[the2nd at otpme.org]

On 2015-01-20 22:07, Alexander Bokovoy wrote:
> On Tue, Jan 20, 2015 at 10:36 PM,  <the2nd at otpme.org> wrote:
>> 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?
> Yes, it omits details of that one, though it covers implicitly that
> there is at least one preauth method (timestamp).
> You need to draw a line somewhere for a beginner 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.
>> 
>> 
>> 
>> 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?
> Host principal is the principal of the machine, yes. FAST armor key
> can be generated in several ways, using an existing TGT is one of
> them. For configurations where you have such keys, i.e. machines are
> enrolled into the realm, it can be used. Other options include
> obtaining a FAST armor key based on anonymous TGT (RFC6112), for
> example. The latter requires working PKINIT setup which is a high
> complexity for many of Kerberos deployments as it would involve a
> separate CA.


does that mean its needed to setup a PKI (in configurations without 
client machine principals) to have the otp securely transferred from the 
client to the AS? it thought this could be done generating a shared 
secret via Diffie-Hellman key exchange?


> 
>> 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?
> See above, RFC6112 gives one possibility to do so.
> 
>> 
>> 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? :)
> RFC6560 with MIT approach to handle OTP is not yet supported by
> Windows Server or client. However FAST PKINIT way via certificates
> infrastructure is supported. You can read more details here:
> http://technet.microsoft.com/en-us/library/gg637807%28v=ws.10%29.aspx
> 
> I think personally that PKINIT-based variant is asking for more
> complexity and thus less useful in interoperability environments. With
> projects like FreeIPA we have ways to manage and deploy certificates
> more easily but still, on Kerberos level issuing short-living
> certificates for OTP handling isn't as efficient and manageable as
> what MIT Kerberos did implement.

i think OTP and PKI are two different approaches to make user 
authentication more secure and i dont know why one (OTP) should depend 
on the other (PKI/PKINIT). but maybe thats because i'm new to all this 
stuff.. :)

however, to come back to the original topic. what i wanted to know is, 
if it would be possible to use the OTP tool i'm currently writing 
(http://www.otpme.org) with samba/windows and standard login procedure.

if my understanding is correct it would be possible to plug in otpme at 
the preauth stage. if the AS would hand over the preauth data to otpme 
(socket or whatever) it could try to decrypt the preauth data with each 
(e.g. 5 minute time range) otp it generates and check if it gets a valid 
timestamp. the otp that successfully decrypted the preauth data could 
then be send back to the AS and then be used just like its done with any 
static password.

do you think this would be possible or do i miss something?

regards
the2nd