[Samba] OTP authentication

[Alexander Bokovoy]

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

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

-- 
/ Alexander Bokovoy