[Samba] OTP authentication

[the2nd at otpme.org]

On 2015-01-21 08:21, Alexander Bokovoy wrote:
> On Wed, Jan 21, 2015 at 1:00 AM,  <the2nd at otpme.org> wrote:
>>> 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?
> What Microsoft decided is to use a short-lived certificate issued by
> an OTP server to the client to signify that this client did in fact
> knew and presented the valid OTP value. The certificate then is
> presented to KDC as part of PKINIT sequence and CA used by KDC knows
> that the cert was issued by an OTP server (they actually share the
> same cert database but this is an implementation detail). As result,
> in Microsoft implementation OTP validation is outsourced to the
> credentials provider on the client side and once the credentials
> provider completes OTP validation with an OTP server, the client then
> decides to get a TGT based on this short-lived certificate issued by
> the OTP server.
> 
> Regarding a shared secret see below.
> 
>>>> 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.. :)
> You need to look at it from historical perspective. While RFC6560 was
> in works, many companies tried to provide OTP-based products to the
> market. They used solutions which already existed, at expense of being
> incompatible or not compliant to what was still in draft. RSA chose
> one way, Microsoft chose another, finally, MIT chose own variation by
> bringing the whole process within Kerberos exchanges under FAST.
> 
> What's important, OTP secrets need to be passed to the validating
> party securely. A secure channel for this could be built in a
> different way but within Kerberos protocol FAST seems to be a natural
> approach. Encrypted FAST channel is the key to establish here but then
> again we have an issue of trusting the channel. Using known principals
> (i.e. host/<fqdn>) would work if their keys are sufficiently
> protected, like in the case of host/<fqdn> on Linux where the same
> principal is used to drive SSH server GSSAPI authentication. Using
> PKINIT works too if all involved certificates are correctly set up and
> verified (Kerberos KDC requires certain extensions to be enabled in
> the certificate to indicate its usage for PKINIT). Using anonymous
> PKINIT would work too -- again, if its usage is limited to certain
> cases.
> 
> A shared secret between KDC and a client enrolled into a realm is
> basically a service key already, i.e. key for host/<fqdn>, for
> example. If you want to use a shared secret based purely on a session
> you are establishing, you need to deal with the MITM attacks.

now i got it. :) i first thought MITM would not be possible because both 
sides (client and KDC) know the OTP (presentation: The 
must-encrypt-nonce variant
). but if the otp must be verified by a (commercial) OTP server the kdc 
does not know the otp and thus there is no way to proof the "identity" 
of the server.


> Getting back to Samba -- domain environment means machines are joined 
> to the
> domain and thus all have host/<fqdn> keys which can and in my opinion
> should be used.


but this is not supported by windows, i guess?


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

> You need to find out if Heimdal supports this communication. In case
> of MIT Kerberos both server and client sides have ability to plug into
> preauth processing. In addition, MIT Kerberos client side since 1.11
> has special API for preauth conversation as different preauth
> algorithms require different data, some of which might require
> interactivity with the user.
> 
> As far as I can see, existing Heimdal has old otp implementation which
> uses internal database to store secrets. This code is not in the
> Heimdal version integrated in Samba. Client side of Heimdal doesn't
> support RFC6560 yet (nor server side) so there is a possiblity only to
> go with something similar to what Microsoft did, i.e. overriding how a
> credentials provider works. Or complete OTP code in Heimdal.

talking about samba 4 with kerberos and windows clients, do you know 
what preauth type is used when using standard auth with static 
passwords?

i personally would prefer a solution where no changes are needed on the 
client side. if it would be possible to hand over the preauth data to a 
third party tool for verification, like i described previously,there 
where no need to transmit the otp from the client to samba/kdc. the 
third party tool just needs to return the valid otp to the kdc. there 
would also be no reason to implement all otp types and features in the 
kdc. there are already working otp solutions, commercial and open 
source.

yesterday i asked on the freeradius mailing list if it would be possible 
to use a radius request/response for otp verification (via preauth data) 
and returning of the valid otp.

http://freeradius.1045715.n5.nabble.com/encrypted-response-parameter-td5731415.html

it looks like this would be possible as there is an response attribute 
"Tunnel-Password" which is encrypted.

however, implementing most of this is out of my scope as i dont have the 
(coding) skills to do it. ;)

so it depens on, if there is someone else who is willing to implement 
it.
but i think many admins would be happy if it would be possible to use 
OTPs without the need for any client changes.
and i also think that at least other open source projects like 
privacyidea would be happy to add support for this.

my perfect setup would look like this:
- setup freeradius with an tool like otpme that knows how to verify 
preauth data
- configure samba/kdc to send preauth data via a radius request to this 
server and get back the clear text otp over an secure channel

using radius would also be nice because i guess it could also be used in 
samba3 environments where no kerberos is envolved. i'm not sure about 
this but i guess it should be possible that samba3 sends an mschap/ntlm 
request via radius when a user logs in?

btw. Alan DeKok from freeradius is willing to help with the radius part 
if there is someone who is interested in implementing this.

i personally woud be really happy about such a feature as samba is 
currently the only oss software i was not able to get going with otpme.

regards
the2nd