Implementing a KDB plugin

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing a KDB plugin

harsh savla
Hello,

I have a use case where I need to authenticate Kerberos principals against
a RESTful Cloud service. This service can talk to an Active Directory(AD)
which maintains the users passwords. On the client side we have a Linux
based VM which runs the MIT Kerberos server. It has also Samba running.

The idea is that end users map Samba share using map drive and enter their
Kerberos credentials. This hits our VM (specifically the krb5kdc service)
and we just pass these credentials to the cloud service which then
authenticates against the AD. Once authentication is successful, ticket is
given to the client.

So in this case the kdb plugin is going to have to talk to the cloud
service. Is it possible to implement this kind of plugin? I see that there
are a few kdb implementations already available under
krb5-1.14.2/src/plugins/kdb/ namely db2, hdb and  ldap.

Thanks,
Harsh
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a KDB plugin

Greg Hudson
On 05/05/2016 02:57 PM, harsh savla wrote:
> The idea is that end users map Samba share using map drive and enter their
> Kerberos credentials. This hits our VM (specifically the krb5kdc service)
> and we just pass these credentials to the cloud service which then
> authenticates against the AD.

Kerberos KDCs do not generally receive the user's password from the
client.  Instead, the client and KDC leverage their shared knowledge of
the password (more specifically, a long-term key derived from the
password) to authenticate and create a ticket-granting ticket for the
client.  Therefore, it is not possible to create a KDB module which
causes the KDC to act as a pass-through password authentication service.

With some caveats, it is possible to do this using the FAST OTP preauth
protocol (RFC 6560).  In our implementation, you would do this by
creating a local RADIUS server which authenticates the client's
otp-value (which could just be a password) against a third-party
service.  The two caveats are (1) you must deploy FAST on the client to
protect the communication between the client and KDC, and (2) this
preauth mechanism is only implemented by MIT krb5 clients, not Microsoft
or Heimdal.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a KDB plugin

harsh savla
Thanks for the reply. I am aware of the fact that the user's password won't
be transferred plain-text or even encrypted over the wire.

I was thinking along the lines that the security blob (encrypted using the
user's password as a key) received by the krb5kdc service on user login
will be passed to the cloud service via the kdb plugin. The cloud service
then passes this blob to the AD (Windows Active Directory) service. AD, as
it supports Kerberos, will have the long term keys stored for all the
users. So it should be able to authenticate the blob.

On Thu, May 5, 2016 at 12:41 PM, Greg Hudson <[hidden email]> wrote:

> On 05/05/2016 02:57 PM, harsh savla wrote:
> > The idea is that end users map Samba share using map drive and enter
> their
> > Kerberos credentials. This hits our VM (specifically the krb5kdc service)
> > and we just pass these credentials to the cloud service which then
> > authenticates against the AD.
>
> Kerberos KDCs do not generally receive the user's password from the
> client.  Instead, the client and KDC leverage their shared knowledge of
> the password (more specifically, a long-term key derived from the
> password) to authenticate and create a ticket-granting ticket for the
> client.  Therefore, it is not possible to create a KDB module which
> causes the KDC to act as a pass-through password authentication service.
>
> With some caveats, it is possible to do this using the FAST OTP preauth
> protocol (RFC 6560).  In our implementation, you would do this by
> creating a local RADIUS server which authenticates the client's
> otp-value (which could just be a password) against a third-party
> service.  The two caveats are (1) you must deploy FAST on the client to
> protect the communication between the client and KDC, and (2) this
> preauth mechanism is only implemented by MIT krb5 clients, not Microsoft
> or Heimdal.
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a KDB plugin

Greg Hudson
On 05/05/2016 05:25 PM, harsh savla wrote:
> I was thinking along the lines that the security blob (encrypted using
> the user's password as a key) received by the krb5kdc service on user
> login will be passed to the cloud service via the kdb plugin.

It may be possible to gateway from the Kerberos protocol to a web
service and back to the Kerberos protocol again, but the MIT krb5 KDC
cannot be transformed into such a gateway element by a KDB module.  KDB
modules can control how principal metadata and key data is retrieved,
and can participate in some policy decisions, but they cannot make
radical alterations to the basic protocol flow.

We do implement an HTTP proxy protocol called MS-KKDCP in our clients as
of release 1.13, but it's a bit different than what you describe.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implementing a KDB plugin

Rick van Rein (OpenFortress)
In reply to this post by harsh savla
Hello Harsh,

> I have a use case where I need to authenticate Kerberos principals against
> a RESTful Cloud service. This service can talk to an Active Directory(AD)
> which maintains the users passwords. On the client side we have a Linux
> based VM which runs the MIT Kerberos server. It has also Samba running.
>
Please note that I am drafting an integration method for Kerberos +
Diffie-Hellman
into TLS, known als TLS-KDH.  I think most questionable parts are gone
nowadays,
and we are implementing this for a client and server side.  This work is
scheduled
for delivery on July 1st.

http://tls-kdh.arpa2.net
https://tools.ietf.org/html/draft-vanrein-tls-kdh

What you seem to want (KRB --> REST --> KRB if I understand correctly) would
easily run into timeouts of Kerberos clients which may be as low as 1 second
and are not generally user-tunable.  I bet you said HTTP and meant HTTPS,
which would aggravate the chances of a timeout.

-Rick
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev