[Samba] OTP authentication

Tue Jan 20 14:07:56 MST 2015

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.

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

-- 
/ Alexander Bokovoy